> The use of resultsets and a TTL strongly depend on the nature
> of as well client as server. If there is a need for some
> applications to have the client set the TTL why not let them
> do that? It is up to the server to support it and to take
> care of its own strategy with respect to dealing with the
> TTL's. We have the mechanism that returns unknown parameters
> in the tag <unkown> so we can be quite flexibel in allowing
> optional parameters. The only thing we have to do is that we
> agree on those parameter names, so that applications that do
> support it will at least use the same parameter name.
I'm not arguing against TTL negotiation per se just that it should be a
new (optional) operation rather than overloading and substantailly
chaging the current searchRetrieve operation and model.
For interactive clients, poking the server to keep a result set alive is
in many cases sufficient and given there is no absolute guarantee a
result set will not be deleted before its TTL or in our suggested TTL
negotiation that a server will grant that the client requested TTL, a
client would need to be willing to drop down to the "poking the server"
approach anyway.
The only use case so far suggested where a TTL negotiation is essential
is where the client expects to be able to resume a result set after a
relatively long period of absence (possibly when the client wasn't
running). That I think is a whole new model of operation and better
served by a TTL negotiation operation (or operations) rather than new
parameters to searchRetrieve.
(We had similar arguments over whether searchRetrieve should be
overloaded to return explain data).
Matthew
|