RE: OPES protocol, pre-draft 01


hi,

+1 

Abbie

-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com] 
Sent: Wednesday, February 26, 2003 2:28 PM
To: OPES WG
Subject: RE: OPES protocol, pre-draft 01



On Wed, 26 Feb 2003, Oskar Batuner wrote:

You have convinced me that the difference may be big enough to 
deserve explicit protocol support. However, since the

implementation

code handling each message would be almost the same, it

may be more

appropriate to indicate the difference via an explicit optional 
flag:

  <data-end xid amid [error] reason>
  <message-end xid amid [error] reason>
  <xaction-end xid [error] reason>

instead of having six very similar messages:

  <data-end-error xid amid reason>
  <message-end-error xid amid reason>
  <xaction-end-error xid reason>
  <data-end-ok xid amid reason>
  <message-end-ok xid amid reason>
  <xaction-end-ok xid reason>

The first approach provides explicit error notification

while better

matching the code that is likely to be written to support

the logic.

It also allows us to reuse the same "error" notification

mechanism

with other message types if needed.

Do we have an agreement now? Would you still prefer the second 
approach?


I'd prefer something in between:

  <data-end xid amid [error] reason>
  <message-end xid amid [error] reason>
  <xaction-end xid reason>       -- issued by server,
                                    processing is done,
                                    "you know the results"


Great! We have an agreement on the above messages. Note that 
processor may need to send "normal" <xaction-end> messages as 
well: this is both an application-dependent and OPES service 
dependent issue that we probably should not restrict too much 
without good reasons.

  <xaction-abort xid reason> -- issued by any party,
                                "just forget it",
                                results of previous processing
                                can not be relied upon
                                and should be discarded


I agree with the definition. You prefer a specific error code 
for this specific level of error. I prefer to keep it similar 
with the other abnormal messages. Since processor may need to 
send "normal" <xaction-end> messages too (see above), and 
since the final difference between our approaches is minor 
(special message name versus a special message flag), I would 
make the changes to have all <*-end> OPES messages to use an 
optional "error" field for now and wait for more objections/comments.

We have a semantics-level agreement. The remaining 
syntax-level difference may even disappear once we start 
selecting specific bindings and encodings for OPES.

Thank you,

Alex.