OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [business-transaction] BTP, defer new issues to post 1.0


Can I ask that people who want to lodge new issues for deferral provide

title: short and distinct

category: technical, minor technical, editorial

description:
should be self-standing (i.e. not "as we discussed last week" - I can link
to old messages, but the issue should be understandable on its own, and its
much better that you write that than me - you will say what you meant, and
I'm a bit busy with 1.0

reference to old messages - as in the archive - you can state these as
200202/32 (for a bt-spec msg) or main/200203/12 (for the main list) - my
perl script will massage those into links


Peter


(if you really want to make my life easy, the input to the script looks like
this:

:Title: Qualifier to allow automatic completion of all-cancelled cohesions
:Submitter: Mark Little, HP
:Category: m
:Description:
In a traditional transaction system (and presumably for atoms), if I issue a
prepare and get back cancel/readonly from all participants, I don't have to
send anything else to that transaction because I know it has finished. With
cohesions, the situation is different. In some cases I'd like
implementations to be able to free up resources held by the coordinator
implementation immediately simply because there won't be any other
registrations <b>and</b> the application shouldn't have to explicitly
terminate such a cohesion which now has no members.
:Suggested solution:
Have a standard qualifier such that, if following PREPARE_INFERIORS and/or
CANCEL_INFERIORS all the current inferiors have either cancelled or resigned
gone away, then the cohesion is finished, and replies with
TRANSACTION_CANCELLED. Default is not (CANCEL_TRANSACTION would be
required).

though now they say Defer, not Title.  Category codes are M, m, E, e (for
historic reasons). The script recognises (and preserves) most of the common
html tags.



> -----Original Message-----
> From: William Z Pope [mailto:zpope@pobox.com]
> Sent: 12 March 2002 04:07
> To: OASIS BTP (Main List)
> Subject: [business-transaction] BTP, defer new issues to post 1.0
>
>
>
> BTP'ers,
> We are closing in on draft 1.0 of the spec, working towards the
> committee draft.
> To that end I am proposing that all new issues raised at this point are
> automatically entered into the issues list with status set to
> "deferred."  This
> bounds the work to be done to complete the spec.  This enforces
> the decision
> voted on in November of 2001 to close the list to new issues but
> ensures that
> issues are not lost.
>
> The committe can vote change individual issues from deferred to
> open (or some
> other status if that's appropriate).  This allows critical issues to be
> addressed.
>
>
> =bill
>
> William Z Pope
> zpope@pobox.com
>
>
> ----------------------------------------------------------------
> 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