[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [bt-spec] Face-to-face
Great. Many thanks. Mark. ----- Original Message ----- From: "Geoffrey Brown" <Geoffrey.Brown@oracle.com> To: "Mark Little" <mark_little@hp.com> Cc: "BT - spec" <bt-spec@lists.oasis-open.org> Sent: Thursday, May 02, 2002 7:53 PM Subject: Re: [bt-spec] Face-to-face > Mark, > > This is all reasonable to I .. you will have a revised submission by next > Thursday. > > Geoff. > > Mark Little wrote: > > > Gladly risking being seen as the "bad guy" again in this issue, here's what > > I'd like to see in order to expediate a decision on issue 89 at the > > Newcastle f2f: > > Prior to the face-to-face I'd like to see a detailed description of > > *exactly* what the issue is (including a use case) and why the proposal > > solves this. We've already agreed that we need to see this at least a week > > prior to the meeting before we can even consider voting on this issue. What > > I don't want to happen at the face-to-face is for it to degenerate into a > > "find the use case" situation; assuming that state serialization appears to > > be a valid requirement, then if it is at all possible to address the > > use-cases in another way within the current bounds of BTP I think we should > > not vote on the issue at the face-to-face, rather than run the risk of > > voting and having a no vote (OK, this is definitely a personal opinion). If > > we were not up against a hard deadline and this sort of thing happened, then > > we'd do what we have done at previous meetings: told individuals to go away > > and come back at a later meeting with an updated proposal for > > re-consideration; we don't have that luxury now. If the committee decides to > > vote anyway then that's OK, but presumably that's it as far as state > > serialization goes in *any* version of the specification? (Not sure about > > procedure here, so I'm more than happy to be corrected on this one, but > > given what happened in the past with regard to certain BEA proposals I'd > > have to assume I'm right.) > > > > The reference to "find the use case" is simply that if we can address all > > of the proposed use cases within current BTP then we again run the risk of > > people trying to come up with other use cases on the fly to justify the > > proposal. To then expect the committee to look at these and determine > > whether or not they are actually new and can only be addressed by this > > submission is not realistic IMO. This is the reason we've asked for *full* > > issue text a week prior to the meeting; otherwise we may as well just wait > > for everything until the face-to-face. I'd like to have all text that is > > necessary to consider this issue on my desk 7 days prior to the > > face-to-face: if that's not possible then perhaps it is an indication that > > the issue is not fully thought out. > > > > It is also ridiculous to say that this issue has no impact on the rest of > > the specification. First of all, it could be said that if it has no impact > > then why do we need it?! Secondly, as I've said on several occassions, and > > I'll try to put it another way this time, this is a bit like a product > > developer saying "we'll add this feature to this release as a place holder > > and we won't document it much as we don't expect people to use it much, and > > in a later version we'll come back and fix it; it'll not cause us any > > problems." Then later when they find that the place holder is insufficient > > for their requirements, they find that someone(s) has actually used the damn > > thing and now relies upon it such that changing it is out of the question - > > must remain compatible. So, now they either have to not put in place the > > real solution using this "place holder" or they basically have to add > > something else which does the right thing but (probably) duplicates some > > (much) of the work of the place holder. And all because they wanted a place > > holder for a feature they were going to add later. > > > > So, let's forget about this place holder red herring that people have been > > mentioning in emails (as I've said before, it's a weak "argument" for adding > > anything to any specification): there either is, or is not, a problem and > > therefore their either is, or is not, a solution for it. If there really is > > a requirement for this then I for one will vote for it. My gut instinct > > tells me that whatever the problem is, state serialisation is only a step > > towards a solution. The questions we need to ask in relation to this (and > > have answers for) include a) why do I need to serialise state, b) how do I > > serialise state, c) (related to b) on what trigger do I serialise state, d) > > how do I get state around, e) are there any restrictions on the use of this > > state. I'd be much happier voting on a solution that addressed all of these > > aspects rather than on just one. > > > > Finally, saying it's optional is no argument at all. That's exactly what we > > don't want in a standard - more options. More options means less > > compatibility and interoperability. Been there, done that, didn't like it > > much! > > > > 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