RE: [bt-spec] FW: Issue 89

[Peter Furniss <peter.furniss@choreology.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:

> <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. So we just define the format, and it is someone else's problem
to say
how it is transferred.

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. 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.

But regardless of the technical details, Oracle say they need to have some
kind of serialisation for BTP nodes. 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.  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. Will it make it harder for others to implmement ? Definitely not,
because it's optional. 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.  But putting it in 1.0 says
clearly that we agree to allow this kind of mechanism.


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.

Peter