Re: [bt-spec] FW: Issue 89

[Mark Little <mark_little@hp.com>]

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