RE: OPES protocol, pre-draft 01

Alex,
we are talking about abort. And saving CPU time. And cleaning the mess 
possibly on may machines and pipes.
At 22:29 26/02/03, Alex Rousskov wrote:
> On Thu, 27 Feb 2003, jfcm wrote:
> > At 17:24 25/02/03, Alex Rousskov wrote:
> > >         <data-end xid amid [error] reason>
> > >         <message-end xid amid [error] reason>
> > >         <xaction-end xid [error] reason>
> >
> > Why not also just?
> > <zap xid [error] reason>
>
> What would be the meaning of the <zap> OPES message? The three old
> messages above are based on three persistent "objects" or "states"
> that OPES protocol has to maintain (data flow, application message, and
> application transaction). See predraft for detailed definitions. What
> does <zap> refer to? How is it different from, for example,
> <xaction-end>?
<zap> as I say would be for the three of them altoegether.
I want to get rid of everything about that transaction.
I do not want to consider anything left which may be ressource consuming or 
unclean anywhere.

> > I just hit escape. We may have extensions of the protocol in the
> > future needing to add other commands. I would hate to review all the
> > code to add <linj-end xid [error] reason> etc. all the way through.
>
> We cannot discuss or accommodate nonexistent extensions because we do
> not even have an extension framework yet.
Well this will just introduce it :-). What I mean is that <zap> meaning
"to kill immediately whatever is related to the transaction", will also
kill whatever extension we may add in the future.

> What can be extended? How? Without such a framework, I cannot (yet) say 
> whether new <*-end>
> messages may be needed.
Right. But I do not want that. <zap> means that everything related to that 
transaction "never existed". You must understand that if you start 
considering messages and logger for every transaction of this protocol, in 
some kind of use, the protocol may be larger than the data, and disk access 
to take more of the machine time.
> "Hitting escape" in a user agent usually means the end of the
> application transaction, which is already supported with the
> <xaction-end> message.
I said "also". Instead of your three messages, one zapper.

> OPES is not about user actions or interfaces
> though. It is about modifying application protocol messages.
(1) it was an image. (2) that has direct implication on the protocol.

Let say that I call a web site through a translation OPES. If it is too 
long to wait or if text comes by parts, I want to be able to escape. This 
information is to hit the translation CPU asap. As a translation operator I 
want to save every CPU time I can to provide the fasted and smoothest 
service. And if it is paying not to be cheated.
> In general, if OPES protocol deals with some kind of persistency (like
> data flow or transaction state), there has to be a way to end that
> persistency. In most cases, you want the flexibility of ending one
> persistency without ending others that are external to it. For example,
> ending an application message must not end transaction processing (in
> general) because a transaction may include many semi-independent
> application messages. That is why we have the three <*-end> messages
> now.
Certainly. But here is not the case we discuss.

> If we discover that there are too many persistent "things" that need to
> be terminated, we would have to redesign and/or, perhaps, introduce a
> meta-message like the one below:
>
>         <end what xid ... [error] reason>
"what"?

BTW: we are in real-time multi-processor environement. If you want to keep 
track of all the "things" you may have to terminate at a given time without 
having any zombie, you may have to have a much more complex system.
Also, the servers must know they face an emergency situation because they 
may have to react differently from a normal termination. They do not expect 
any emergency in a standard <xaction end>.
jfc