[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: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC