[Top][All Lists]

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

[help-GIFT] Re: Understanding MRML: undo

From: Wolfgang Müller
Subject: [help-GIFT] Re: Understanding MRML: undo
Date: Mon, 8 Jul 2002 11:41:27 +0200

> 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.

I see this point.

> Since letting the server track the state solves the problem most
> general, I would go this way (-- and therefore drop the
> "history-backward" someday).

Hmm. I would really like to see some non-me, non-Freiburg input on that. Do 
you all agree with this? I agree witht that at the time being. I still would 
keep user-data in, though.

> 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.

I think the algorithms configured within a session determines what a session 
can do, so I guess most of the stuff belongs into the algorithms. Surely 
stuff like the communication itself is not part of the algorithm's business.

> Could you give an example of an algorithms property which you would
> like to put into the query-paradigm-list?

The way interaction works, the indexes the algorithm expects.

For collections: the data types we can get out of it.

> > > 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?

I meant exactly what you write below.

> 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.


reply via email to

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