RE: [bt-spec] Re BTP Issue 103 (was issues 100, 101, 103 and 105)

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

I really don't understand why it makes a lot of difference whether the
BEGIN, BEGUN exchanges are

related-group
	begun
		decider-address
		transaction-identifier
	context
		superior-address
		superior-identifier
		superior-type
		qualifiers

(using indentation rather than xml angles)

against

begun
	decider-address
	transaction-identifier
	superior-address
	superior-identifier
	superior-type
	qualifiers

(unless you are arguing for some defaulting, which could be arranged anyway
on begun)

In the former case, the context is already there and ready to stuck on the
application message, whereas in the latter it has to be constructed. It
might be different if we had separate schemas for the different
relationships, but when we discussed that it seemed a bad idea because there
were too many overlaps.


Is it only the BEGUN&CONTEXT, BEGIN&CONTEXT groups you want to merge, or to
go back to containment for the other groups too ?  In fact, are you wanting
to change BEGIN as well, with optional superior-address and
superior-identifier - BEGIN & CONTEXT is a lot more like putting CONTEXT
with an application message (though it isn't quite the same)

another note at end:

> -----Original Message-----
> From: Mark Little [mailto:mark_little@hp.com]
> Sent: 18 March 2002 10:41
> To: Alastair Green; BT - spec
> Subject: Re: [bt-spec] Re BTP Issue 103 (was issues 100, 101, 103 and
> 105)
>
>
> > The existing specification text is implementable, and produces a desired
> > behaviour which helps to enforce transactional integrity.
>
> I would hope so given the effort expended so far. However, our proposed
> change would not affect this at all - if it did then I would certainly
> consider removing it or at least leaving it to later.
>
> > It can, at some level, be reasonably criticized: you could make
> a case for
> > splitting CONTEXT into ENROLLEE and CHECK, and renaming CONTEXT_REPLY to
> be
> > CHECK_REPLY. Then you would never see checking info (i.e. the reply
> address) in
> > ENROLLEE, and explicit control over checking would become possible (send
> > ENROLLEE only, or send ENROLLEE & CHECK).
>
> You could certainly make an argument for this, but we're not
> proposing going
> even that far. All we are proposing is removing the CONTEXT
> message entirely
> from the BTP "protocol layer" (bad name, but basically we mean
> that part of
> a "system" that is purely involved with talking to the coordinator(s) and
> not involved with application specific interactions). This should be a
> single change in the specification:
>
> - add CONTEXT (or the information that is embedded within CONTEXT) as the
> payload within the BEGUN message. If there is no CONTEXT then we have the
> BEGUN as it currently stands. Thus, CONTEXT as a message only ever appears
> within application messages.
>
> > However, it appears to us that checking is a 95+% case in this
> environment, and
> > that the weight of a single excess element (which is not
> present when not
> used,
> > i.e. in the BEGIN/BEGUN and Cohesion CONTEXT propagation cases) is not a
> great
> > overhead or trouble.
>
> I think you've got the wrong end of the stick. We are not pushing for
> removal of any messages or their functionality.
>
> > Our view, for what it's worth (2/20 votes), is that change in this area
> would be
> > possible, and even theoretically sweet, but is not strongly justified at
> this
> > stage in the life of the spec. We also suspect that
> implementation/deployment
> > experience would assist in further evaluating the type of change
> envisaged.
>
> This is based on implementation/deployment experience. Obviously the more
> implementations that are out there the more experience gained,
> but we're not
> coming at this from the "theoretical" stand-point.
>
> > So, I would propose "defer" as the solution to the this issue.
>
> I don't think this is a big issue and we can certainly live with it either
> way. However, if we are to change it, we'd prefer to do it now
> and not have
> to worry about any legacy implications.
>
> >
> > It would be useful to see a concrete textual alternative, with
> all of its
> > ramifications worked out, if another resolution is proposed.
>
> See above.

I don't see "proposed solution" text here, or a change-marked text. Changes
would need to state the new parameters and explanation of them for BEGIN and
BEGUN, and new text for CONTEXT to say where its values came from (iff the
standard control Initiator:Factory relationship had been used). And in the
xml.

Peter