Re: activity context & context poll

[Mark Little <mcl@arjuna.com>]

I also agree with limiting the context to the needs of a cohesion (BT) protocol. The super-context is a) outside our scope/powers and b) arguable. I like the SOAP approach (or the GIOP approach) where many unrelated contexts can travel, and it is a matter of cooperation between different pairs of actors as to how they are interpreted, delegated/retransmitted etc. To take a concrete case in point: what if the rules for delegation are different for security and transactions? I may want to stop propagation in one case, and allow it (or enforce it) in the other.

Yes, I agree completely with this.

Where I do strongly agree with your approach is that context information should be freely capable of being written by frameworks or application instances, as well as standardized services of the kind we're working on defining.

In addition, what we lay down now could well restrict the types of applications that are to be developed in the future. If we're flexible now, then we may prevent this.

So I guess I would only want to see a framework for placing and identifying contexts (perhaps with an IANA like scheme for allocating unique ids for well-known standard contexts), rather than an attempt to tie them all into a super-context. Now, a framework where links are defined (or not defined), and elements may or may not be present may amount to the same thing ...

Again, I agree. Given a transaction-model id (the IANA equivalent) I can then interpret the arbitrary BT-context in a model specific manner, and still ensure type safety (assuming the sender wasn't broken, but that's an issue regardless of implementation).

 

Mark.

 

-----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 206 4538, FAX : +44 207 670 1964
EMAIL  : mark@arjuna.com