Re: [bt-spec] FW: Issue 89

[Mark Little <mark_little@hp.com>]

> In the light of several of the message threads:
>
> As I understand it, what Geoff needs is a format for serialising a btp
node.
> I don't see that we need specify
> exactly how this gets used - I disagree with Mark Little's comment:

Not a surprise I have to say ;-)

>
> > <ml>It is a significant change. It requires us to agree on a
serialisable
> form,
> > to determine what the mechanism for getting the state is (e.g., what's
the
> message
> > set extension?), to agree when this message can be sent, what are
> > the security implications, ...
> > </ml>
>
> I've assumed that these things would be defined in something else, and we
> were concerned
> with making it possible to include BTP nodes as parts of some wider entity
> that was
> moved around.

Different assumption than what appears to be coming out of the current round
of discussions with Geoff. Does lead back to my thread of: let's discuss
this in detail and figure out what it is we want before we add something
that doesn't address the real issue.

> So we just define the format, and it is someone else's problem
> to say
> how it is transferred.

But what if we don't get the format correct? Look at how long it has taken
us to get to the right message set.

>
> Now it is clear that, given a serialisation, there is more than one use
that
> could be made of it. For some of
> these (e.g. recovery), it doesn't seem likely that inter-implementation
> transfers would be likely. But, for other uses,
> perhaps the one's Geoff has in mind, the historic pattern is probably
> irrelevant. Moving the top coordinator around
> is an intriguing possibility, where interoperation (in the
> inter-implementation sense) would be useful.

See lots of previous emails where I have shown that serialising the state is
not a necessary nor sufficient condition to achieve this. In fact, the last
email I just sent shows how we can accomplish peer-to-peer shadowing (and
even replication, migration and cacheing) without a change to BTP at all.

> For some of those uses, there
> might be other ways of tackling the problem - but its also quite likely
that
> those other ways would have problems again, and the mobile coordinator was
> the way to do it.

If mobility is the issue then there are definitely other issues we should be
looking at as well.

>
> But regardless of the technical details, Oracle say they need to have some
> kind of serialisation for BTP nodes.

Agreed and when we see the use case that will feed into the discussion.
Running the risk of re-opening old wounds, I would like to re-iterate what
Mark Potts said in his email about what happened in the past with
*implementation specific* requirements from BEA - Choreology are more aware
of this than others and should tread a careful path in order to seem even
handed.

> Now, we (the TC), could say that we
> will include this is in 1.1 or whatever - but that would just be an
intent,
> and who knows when it will actually be there, or how much arguing there
will
> then be.

Again, agreed. However, I know that if I had an issue that was important
enough to need in a spec. I'd rather it was discussed in full before a vote
occurred that might throw it out because it wasn't. The other alternative is
that we push back the deadline of the 1.0 specification. Do you want to
consider that?

>  Or we could make clear our intent to do so, by putting in
> something in 1.0.  Will it be perfect ? improbable.  It's quite likely
even
> Oracle will want to revise it later, as a result of their implementation
> experience.  Will its imperfections damage the document as a whole ? Not
> really.

And here we disagree again. The current document is already turning people
away from BTP because of its complexity. Do you really want to risk adding
more complexity (and it is not a simple addition, since it will require
background text, checking that the XML is at least good enough for Oracle,
and then what the implementation impact is.)

>Will it make it harder for others to implmement ? Definitely not,
> because it's optional.

Two things:

(i) from the start I've been wary about optionality, but we've added it
because some people don't see the benefits of, for example, cohesions. OK.
However, I'm loath to keep adding more and more optional features. It starts
to erode the interoperability features of BTP.

(ii) as I've said before, whether it's optional or not, it should have a
good use case *and* be correct. I would expect the same from any issue that
we vote on.

> Will it widen the scope and require further work,
> delaying 1.0 ?  Not if we constrain it to an xml definition and an
> introductory text that says it *could* be used.

Disagree. The complete lack of security within BTP is already causing us
some headaches and now we add this?! Please go back and read the very last
email I sent and you'll see an implementation that does not require any
changes to BTP and IMO neatly avoids the security issue.

> But putting it in 1.0 says
> clearly that we agree to allow this kind of mechanism.

"agree" is the correct word. As we are a democratic committee at some point
we will come down to a vote and I would hope that both sides in this
discussion will agree to abide by whatever decision is made: I know we will
and I will stress again that we are arguing against this addition because a)
it's not needed (at least given the current information it would appear we
can do this another way) and b) adding it now runs the risk of delaying or
otherwise worsening the take-up of BTP. This is not an arguement because of
implementation problems, politicing, or anything else.

>
>
> As to the timing of this discussion, the order of going through the issues
> has mostly been by when I thought I understood the problem and had text
for
> it, and I didn't understand this one so well, so it's got left to the end.
> That may be a pity, but that's where we are now. When Geoff joined the
> committe, this issue (and all of the Oracle issues) came in within the
> deadline we'ed set. Geoff has now withdrawn or merged the other issues,
and
> this is the only one he's insisting on. From the perspective of the
standard
> as a whole, this is a "point" issue - it affects only the text it adds.

No, it affects readers, implementers and users alike.

Trying not to sound too much like a broken record: at some point we will
have to decide whether we want to vote or not and if we decide to, then
that's fine; we (HP and others) will have done our best to try to keep the
specification on track and to argue that this issue has not been carefully
enough thought out. However the vote goes, we will live with it and move on.
That's how we have worked as a committee in the past and that's how I hope
we will continue to work.

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250