RE: [bt-spec] Context

[Peter Furniss <peter.furniss@choreology.com>]

Jim,

> I have been thinking (and I know it's dangerous, but..) about the Context
> message and how its canonical use is in the domain of application
> messages.

an important concept, and quite tricky to express in the spec I've found.

> This may be contentious, but how about:
>
> 1. Making the context a pure application-level message, i.e. by delegating
> its creation to the intialiser.
> 2. Adding what would have been context payload into the
> begin/begun messages
> for begin/begun exchanges.
>
> This would give the following benefits:
>
> 1. Context message semantics are much cleaner (i.e. we only see
> it if we are
> an application).
> 2. Simply message exchange for the creation of transactions.
>
> What does everyone think?
>
> Jim
>
> PS - I don't want to start a war over this, it's just an idea.

I think it's probably convenient to have a construct that encapsulates the
information needed to propagate the transaction. It is certainly true that
the content could be broken up and put directly in begun and begin. One
could even, at a pinch, abolish the CONTEXT construct altogether and leave
it to the application to package the former contents, though that is really
a question for the binding (if a binding said the abstract CONTEXT is
transmitted by putting this field here, that field there, it is still
sending the abstract CONTEXT). But assuming BTP provides a packaging, then
it seems reasonable to pass it pre-packaged in or with the BEGUN. And it
then seems silly to make the application break it up again for a BEGIN &
CONTEXT.

The BEGIN&CONTEXT and BEGUN&CONTEXT combinations were the ones that, IIRC,
led us (the tc, the draft) to the now-abandonded idea of encapsulating one
message in another - for these two, having the context inside does fit ok.
But for the other combinations, encapsualtion doesn't work well - hence the
change agreed in issue 85.

as issue list maintainer:  I won't make this a new issue unless you ask, but
will if you do.

Peter