1. Logistics/ws-context schedule
We've had a successful meeting - need to have another go-round, editors'
draft, review
There is still an issue-to-be-submitted from Alastair. To be put on agenda
for next phone meeting.
Martin suggests a target for a document for vote in first week
Sept
Alastair - need to have the text 2 weeks before a vote
Martin: intended category of this document - committee draft would seem
appropriate
current meetings schedule:
various patterns of drafts considered. Conclusion:
2 August: submit and resolve all outstanding independent issues (addressing
issue/alignment with ws-rel may still be open)
(meeting confined to
context matters only)
9 August: circulate 0.5 draft containing all issue resolutions
(from now till circulation of voteable, all are expected to carefully
review the draft and submit editorial comments,
editors polish text to
produce draft to vote for CD)
16 August - normal meeting
23 August: circulate candidate draft
30 August: - normal meeting; initiate vote to approve candidate as
Committee Draft
6 Sept: (7 days from vote opening) vote concludes
Next face-to-face:
Possibles:
Brussels - OASIS plenary week - October
4th.
Prague - same week
Dublin - same week
Prague chosen
timings considered:
4, 5th all day
4 pm, 5, 6
am
5,6 all day
preference vote of those attending
here:
Conclusion: 5th, 6th,all day
Further out: dec/jan,
probably east coast (oracle mt laurel ?)
(pattern up to then: Boston,
Paris, New Orleans, San Francisco, Prague )
2.
Coordination Framework
How to bootstrap work.
Martin: WS-context has changed, and there is a need for a revision of
it
Also need to have general discussion on model and cf as a whole
Greg - things are simpler now
before:
client/app <-> context service
<-> als
this had problems on the
cs:als interactions, what had to be kept
cf was
defined as an als - als is also a cf, so cs:als/cf interactions had
to be dealt with
complete to cs with cf - there is a registration exchange that
allows
communication through the tree (though its up to the coord pcol
whether
that is used)
after: (i.e. now, post NO)
c/a <-> context service, how does cf
how to the express cs : cf
relationship
what was an als is now in a sort of inheritance
relationship on cs
ag: could use the cs mechanisms,
extended/overloaded to tree build (the begin+context)
but with
cf it's suggested that a different tree building mechanism is
used
greg: not the way existing transaction systems work -
nesting is tied to demarcation api, enlistment is
internal/invisible
the discussion
continued
greg, martin: distinction between relationship
between participants and relationship between
activities.
participants are members of an
activity
sub-activities (nested a) are a particular kind of
participant
ag: consider a tree of things
and
interposition
addParticipant builds trees. these
could (but need not) load the parent-context fields. If they do and
begin+context is used as well, then we have two ways of tree building - or there
is another way of holding the trace
Martin: depends on
type of thing added - use one if it is an activity, addP if
not
alastair: as with WS-C, cf doesn't currently allow
general tree building, with no hierarchy. Dynamic commit (as the general
movement of the coordination point)
also can't have
differential coordinate to subsets of participants
WS-C
doesn't have the "active" parts that are in ws-cf - only the tree building
(registration, address exchange). this is a better split of responsibility - the
higher specification should be responsible for the demarcation, completion and
coordination signals
a tree-building p'col is
useful.
greg: context has virtue as activity concept, apart
from tree-building
activity has lifecycle characteristics -
they begin, they run, they complete
martin: if we make
ws-cf not use begin, complete etc, and only use the context, then we've messed
up
greg: we can extend these, cf adds semantics to the ws-ctx
begin, complete
alastair: e.g. dynamic commit wouldn't use coordinate or
complete - the completion of the transaction uses other signals.
consider also an upcoming cancel (greg: or timeout expiry) which would also
cause completion
greg: what proportion of higher specs
would NOT use complete etc.
martin: no point in a generic
mechanism that nothing uses.
Choreology list of issues.
Martin can choreology put these into bugzilla ?
Better to treat these as inputs to the editors revision /alignment of the
ws-cf specs.
Editors: take into account the choreology comments as part of the revision
of the ws-cf to align with the changes in ws-context. Some of the comments
may survive this and then should be entered as issues proper.
Back to cf concepts.
greg: asks alastair if e.g. open-top 2pc
pcols can't be supported by cf/ctx
alastair: can be supported, but would be constrained or have to re-write
the rules for e.g. complete
...
could have overloading of coordinate, complete, which in some cases
triggered the underlying complete message/signal
Martin: would like to see an analysis of the known candidates (txm's 3,
btp, ws-tx's 2) and whether they would use/be comfortable with the ws-ctx
complete, ws-cf coordinate. Impact on ws-ctx complete and ws-ctx
timetable.
try and get some finger-in-the-air as to whether the use of these
is never, rare, common, usual, always.
Informal action point:
omnes/volunteer
Motion to adjourn: 12:10 pdt.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]