[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [bt-spec] FW: Issue 89
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC