[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] FW: Issue 89
Agreed. However, as indicated earlier, we (or you, I'm not sure which given the rules) should have a fallback position in case it is decided that we don't have enough time to discuss this sufficiently to satisfy you. Mark. ----- Original Message ----- From: "Geoffrey Brown" <Geoffrey.Brown@oracle.com> To: "Mark Little" <mark_little@hp.com> Cc: "Peter Furniss" <peter.furniss@choreology.com>; "Bt-Spec" <bt-spec@lists.oasis-open.org> Sent: Monday, April 22, 2002 11:43 PM Subject: Re: [bt-spec] FW: Issue 89 > > Folks, > > I think that we need to discuss this one a little further ( after the > publication of a use case & more detail ) .. I honestly think the idea has merit > and it is based on a complex problem that I face ( and I gather I am not alone > on this ) ... the key thing is that everyone should see the VALUE and SENSE in > this proposal ... the very last thing I want is for anyone to perceive that > ORACLE is using a BIG STICK .. which I clearly want to avoid at all costs. Hence > why this part of the specification should be OPTIONAL. > > Rgds, > > Geoff. > > > Mark Little wrote: > > > > 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 > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.oasis-open.org/ob/adm.pl> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC