Re: [bt-spec] FW: Issue 89

[Geoffrey Brown <Geoffrey.Brown@oracle.com>]

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>

Attachment: Geoffrey.Brown.vcf
Description: Card for Geoffrey Brown