[Top] [All Lists]

Re: comments on draft-dracinschi-opes-callout-requirements-00

2002-03-01 12:57:43

Condry, Michael W. wrote:

I think mark as a good point here. The service may expect to work with caching functions to deliver the service - other services are not concerned if the data is cached or not.

Just to avoid a possible misunderstanding here - the 'buffering' that was referd to concerns temporary buffering of a response (from the origin server) at the OPES intermediary until a possible callout response comes back (similar to the '204 - no modification' feature defined in iCAP). It does NOT refer to what is mostly meant in the context of Web caching, namely caching of responses (from origin servers) for the purpose of serving subsequent requests for the same Web object.

The benefits of such buffering would be that unmodified messages would not have to be sent back by the callout server. The buffered data would not necessarily be used to serve other user requests (although such buffering could implicitly be realize by having a cache on the OPES intermediary, of course).

I do not know if you consider the caching done by the Lucent translation service to be a cache or not? It does cache, I do not think it views itself as any form of general cache.

Without going into the details of the "translation example", it simply stores a translated version of a requested Web page, in case the user wants to have the page translated some time later. That's certainly different from the kind of "buffering" we were refering to, and, as you pointed out, is also differnt from a general 'caching proxy'.