[graap-wg] asynchronous binding

[Karl Czajkowski]

On Feb 19, Karl Czajkowski loaded a tape reading:
...
> 
> Would a corrected version of the symmetric agreement mechanism satisfy
> your needs here, or do you also still feel that a two-phase creation
> mechanism must be available for asymmetric initiators who will not
> host any WS-Agreement related endpoints?
> 
> 
> karl
> 

While waiting for a response, I dug back in my email archive and found
this comment from Takuya on 1 Dec 2004:

   I added asynchronous request operations
   (e.g. createAgreementAsync), polling operations for getting the
   result (e.g. createAgreementGetResult), and response operations
   (e.g. createAgreementResult).  Please see the attached document for
   detail. It also includes some minor comments to the original
   specification.

but unfortunately my archive does not retain the Word document
attachment, so I cannot review the specific changes. (Does anyone know
of a public archive where I can easily retrieve such GRAAP messages
with attachments?)

Just based on the above summary, I would say that I am proposing we
drop the createAgreementGetResult operation in favor of an equivalent
binding-level behavior to reliably get (or "re-get" by polling) the
result of the existing createAgreement call in case it takes too long
for the baseline bindings.  I am also proposing that we attempt to
incorporate his notion of a "reverse direction" createAgreementResult
operation (which I separated as acceptAgreement and rejectAgreement)
into a repair for the now underspecified and broken symmetric
agreement pattern.

Does anybody else have opinions on these issues?  Will there be a
GRAAP call today (Monday 20 Feb)?


karl

-- 
Karl Czajkowski
karlcz at univa.com