On Tue, 26 Aug 2003, MITTIG Karel FTRD/DMI/CAE wrote:
However, I think we need at least a way to tell the processor if
it's allowed or not to cache specific adapted data.
One example to explicit my need: having a filtering service, you may
want unfiltered content (for any client profil) to be cached by the
processor after the server call (to reduce load on this server), so
the server has to be called before the processor cache mecanism.
However, you will want potentially filtered content and
corresponding adapted data not to be cached because it will be
managed by specific server policy.
So I suggest introducing at least an optionnal flag in DUM message
telling processor not to cache the answer.
I agree that cache control is a desirable feature in many
environments. There are several related observations:
- Some application protocols to not support the
notion of caching (e.g., SMTP).
- Application protocols that support caching
usually have built-in caching controls (e.g.,
Cache-Control header in HTTP). These controls
are often quite sophisticated.
It looks to me that adding cache control features to OCP Core would be
wrong because some protocols do not have a notion of caching at all,
and those protocols that do already have extensive controls that OCP
Core would not be able to duplicate in a generic manner.
How about this:
- Let OCP application bindings handle cache control
issue.
- Recommend that an application binding relies
on existing application controls rather than
extend OCP.
Would that address your needs, including the filtering example you
gave above? Can the filter service alter Cache-Control headers of the
filtered responses appropriately?
Thanks,
Alex.