[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OPES protocol, pre-draft 01
> -----Original Message-----
> From: owner-ietf-openproxy@xxxxxxxxxxxx
> [mailto:owner-ietf-openproxy@xxxxxxxxxxxx]On Behalf Of Alex Rousskov
> Sent: Tuesday, February 25, 2003 11:25 AM
> To: OPES WG
> Subject: RE: OPES protocol, pre-draft 01
> On Tue, 25 Feb 2003, Oskar Batuner wrote:
> > Abnormal termination is different from normal termination (and all
> > other normal messages) in the sense that it switches context from
> > message processing to termination and cleanup. I think this
> > difference justifies presence of a separate message.
> Both normal and abnormal termination switch callout server context
> from message processing to termination and cleanup, don't they? I
> agree that abnormal termination may have side-effects different from
> normal termination. For example, if the callout server caches some
> transaction information, it may want to purge the cache if the
> transaction terminated abnormally.
> > Another difference is that abnormal termination message may arrive
> > at any moment, other messages are limited by the processing context
> > (protocol state machine).
> Good point. This distinction can be useful if an implementation wants
> to ignore/log non-control messages sent on the control channel.
> > In some sense it is a question of preferences - as you have
> > correctly pointed out difference between normal and abnormal
> > termination messages can be determined by some additional reason
> > code in the same message. I prefer to keep an explicit difference.
> 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
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"
<xaction-abort xid reason> -- issued by any party,
"just forget it",
results of previous processing
can not be relied upon
and should be discarded