I would imagine that caching must be possible at each stage of the
processing chain, so that you can compose things like
svc1 -> cache -> svc2 -> cache
svc1-> svc2 -> cache
depending on the particular situation.
This makes the cache effectively a local service itself, rather than an
assumed part of the OPES intermediary. IMO that approach is more
flexible and more clearly defined. It would require that a well-defined
caching model be specified, but would not limit us to one caching model.
The requirements below lead to the need to compose a cache key based
upon a fairly large variety of input. If the approach above is taken, it
would best be communicated to the cache as a parameter. This, in turn,
raises the need for out-parameters from callouts. E.g.,
service chain: svc1 -> cache
in parameters: foo=boo cachekey=abc,def
out parameters: cachekey=abc,def
All that would be needed, then, would be a way to hook up the
out-parameters from svc1 to the in-parameters from svc2 in the ruleset
(probably with some sort of variable, although an approach using URIs
and/or XML IDREFs might be possible).
On Wednesday, March 20, 2002, at 02:37 AM, Frank Berzau wrote:
Responses could be cacheable for just a subset of requests. Example
could be a URL filtering service that returns different responses for
specific groups of users. This becomes an important aspect when looking
at section 3.2.6. If a callout server aggregates multiple responses it
must not only use the earlist expiration, it must also ensure the most
specific caching rule is applied. In some cases there may be situations
where such diverse cacheability rules cannot be contaminated, e.g.
server 1 does language translation and it flags all responses cacheable
per language (as found in the user-agent header). Service 2 does URL
filtering and flags responses be cacheable per LDAP user group. How
should the callout server aggregate this?
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Markus
Sent: Friday, 01. March 2002 21:16
To: Mark Nottingham
Cc: OPES list
Subject: Re: comments on draft-dracinschi-opes-callout-requirements-00
Mark Nottingham wrote:
Perhaps it would be helpful to clarify the interactions between a)
the encapsulated protocol b) the OPES service and c) the callout
protocol. Caching touches all of these in different ways, and that
might be causing the confusion here.
That's a good idea, because there are quite some dependencies between
the various cachability rules (e.g. the possibly modified response
from a callout server must NOT be cached longer than indicated in the
original response from the origin server etc.). We struggeled quite a
bit ourselves when discussing this, so we need some clear