Re: [bt-spec] FW: Issue 89

[Mark Little <mark_little@hp.com>]

> A couple of points as TC chair ...
>
> First, I agree with Mark, let's put the inclusion of this issue to a
> vote and then move on.  We have a process lets use it.
>
> This is the first significant issue where we have had disagreement on
> whether or not the solution should be included in 1.0.  Differing views
> on the inclusion or postponement of this is OK.  Just need to get it
> resolved.  The avenue for resolution of issues, including procedural
> issues, is to vote.  Based on the current discussion I would like to
> treat this issue very formally.
>
> My suggestion is that a vote be proposed on the inclusion or exclusion
> of a solution for issue 89.  That vote can be tied to a particular
> proposed resolution or can be independent of any resolution.  I would
> suggest the former to try to keep this moving but am open to the latter
> as well.

So we vote on including a solution for 89 before voting on what that
solution should be? Sounds strange. We've never done that before as far as I
can remember. If we are going to vote I'd prefer that we have a vote on the
same basis as before, i.e., here's the perceived problem and here's the
solution.

>
> The issue has been in the issues list since Dec 1 of 2001.  It has taken
> a while to get understanding of what would satisfy the issue but that has
> been the case with other issues too.  Some of those have had resolutions
> included for 1.0, some have been deferred.   Precedent then, allows
> the inclusion of this issue to go either way.
>
> I am in favour of including a resolution of this issue in the 1.0
> draft.   That prejudice is stated here to recognize it and any effects.
> I believe that having stated the prejudice I can remain impartial in the
> presentation of the information and the vote but do want to allow anyone
> in the TC to challenge this and possibly bring in someone else to run
> the vote on this issue.

I don't have a problem with you remaining chair on this one. It's
impractical to think that the chair can be impartial for every single vote
we have (or have had).

>
>
> So, following on in that vein a couple of points NOT as TC chair ...
>
> I am concerned about the impact on the schedule that this may cause but
> IMO including a solution for issue 89 is low risk.  Here's why I think
> that's true.
>
> It is optional.  While this has some negative consequences on spec
>   complexity this is such a discrete item that the impact on complexity
>   is low.  The optionality is expressed by making the externalized state
>   a separate conformance item.  Implementations can choose to support it
>   or not.

I'm not going to go over old ground again in detail, but: we can have too
many optional features (blows the interoperability/portability BTP out of
the water eventually) and why have an optional feature that may be
broken/not required?

>
> It is contained.  It has no impact on the rest of the protocol.

Disagree.

> The
>   resolution of this issue does not include anything other than the
>   representation of the externalized state.  It will not include
>   interfaces or messages to exchange state or query state, etc.  This
>   constrains the impact on the document to the state format, the
>   conformance statement, and a descriptive text in the spec and the
>   model.  The descriptive text must include suggested use cases.  It
>   need not include the definitive list of potential use cases.

So I fail to see what use it will be at all then!

>
>   I agree that there are other more important issues that need to be
>   addressed but all of these have a substantially larger impact on the
>   current specification.
>
> This is a placeholder to provide a basis for experimentation.  As such
>   we don't need to get this 100% right the first time.

We do if people implement it, code applications against it and then we try
to change it in the future. As soon as something becomes concrete it becomes
more difficult to change it, even if it is broken. You only have to look at
other standards organisations to see that.

>
> The conformance for the externalized state should allow for extension
>   of the XML format.  This allows implementations to add to the format
>   and remain conformant.
>
> Regards,
> =bill
>

I'd like to see the use case first and then see if the solution I mentioned
over the weekend does, or does not, address it. I would have thought that we
would look at every issue from the point of view of whether or not it can be
solved already by the protocol. If we don't do that then how can we ever
throw any issue out?! If the members of the committee are looking at issues
from another perspective then I'd like to know.

Mark.

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark_little@hp.com
Phone: +44 191 2606216
Fax  : +44 191 2606250



>
>
>
> -----Original Message-----
> From: Mark Little [mailto:mark_little@hp.com]
> Sent: Sunday, April 21, 2002 11:21 AM
> To: Peter Furniss; Geoffrey Brown
> Cc: Bt-Spec
> 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.
>