Re: activity context & context poll

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  :