[bt-spec] Face-to-face

[Mark Little <mark_little@hp.com>]

 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