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