Re: [bt-spec] Face-to-face

[Geoffrey Brown <Geoffrey.Brown@oracle.com>]

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