[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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>
Attachment:
Geoffrey.Brown.vcf
Description: Card for Geoffrey Brown
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC