OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [bt-spec] FW: Issue 89



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. 

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.


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.

It is contained.  It has no impact on the rest of the protocol.  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.
    
  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. 

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  




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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC