RE: JW8: results cacheable?

Alan Babich writes:
> The client can cache results or not. On a readonly document
> space, cacheing would usually be a good idea. On a
> space that is updated on line, maybe it wouldn't be such
> a good idea. A conservative client wouldn't cache, but I don't
> want to require that.

Well, it seems a bit simple to say that a client "can cache results or not",
since currently there is no caching support in the DASL specification.  If
caching were to be supported, I'd expect some searching equivalent of the
entity tag that a client could submit to the server, along with a search
request, to see if the search results had changed since the client last
cached them.

It seems to me that either DASL will be used against an authoring server,
whose contents will be changing rapidly, and hence not too conducive to
caching, or the server will be read-only, but have a large number of entries
(some kind of digital library).  In this latter case, though client-side
caching would work well, I wouldn't expect the same queries to be
resubmitted from the same client, thus resulting in low cache hit rates.

Does anyone have any data from digital library searching that might support
or refute these use assumptions?

Based on the assumptions above, and due to its added complexity, I don't
think adding caching support is worth the complexity. It can be retrofitted
in later, if needed.

- Jim

Received on Monday, 16 August 1999 20:04:10 UTC