[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[help-GIFT] Re: Understanding MRML: undo

From: Ralf Juengling
Subject: [help-GIFT] Re: Understanding MRML: undo
Date: 08 Jul 2002 11:22:43 +0200

> > I wonder how this could work, since in general the session has
> > a state on the server site either and this state has to be maintained
> > by the server. Thus, I can imagine this to be useful only in a setting
> > where the session on the server site is stateless.
> Yes, and it's something that is (IMHO) rather algorithm-specific, so I do not 
> think it should be configured server-wide, but rather algorithm-wide. q-p-l?? 

Some algorithms do maintain a state, others might not do so. For those
that are stateless, the former "history-backward-approach" would work.
However, I wouldn't place the burden to track the session state to both,
the client and the server.
Since letting the server track the state solves the problem most
general, I would go this way (-- and therefore drop the 
"history-backward" someday).

> I think (and Ralf thinks that, too) we should make a table about the 
> properties an algorithm has and in what q-p-l attributes we want to pack 
> these values. Then maybe we should get a vote if and how to rename the 
> query-paradigm-list such that the name reflects the thing. This probably goes 
> a bit into the direction of Steph's thoughts on MRML evolution.

Yes, we should set up such a table. But we have to decide which 
properties actually "belong" into the "algorithm" element and which
to put elsewhere.
Could you give an example of an algorithms property which you would
like to put into the query-paradigm-list?

> > To conclude: I propose to introduce a new elemenent
> > "undo-query-step" to request an undo of the last query step from the
> > server.

<!ELEMENT undo-query-step EMPTY>
> ...together with the results of the previous step?

Hm, what was the benefit?

To complete my proposal:
In case the server supports the "undo" tag, the server's answer to an
"undo-query-step" would be the last but one query result; if it does
not support "undo", it would simply resend the last query result along
with an error message.


Ralf Jüngling
Institut für Informatik - Lehrstuhl f. Mustererkennung &
Gebäude 52                                       Tel:
79110 Freiburg                                   Fax:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]