--On Friday, March 1, 2002 11:20 -0500 Markus Hofmann <markus(_at_)mhof(_dot_)com>
wrote:
Mark,
thanks for the comments, remarks inline.
* Abstract - a cache isn't an intermediary, it's a local message store;
'proxy' or 'gateway' would be a better example.
What the abstract meant to say is that an 'OPES intermediary' can - for
example - be implemented on a cache. We can surely include 'proxy' and
'gateway' as well.
A "cache" meaning? We had this definition discussion years ago in WREC...
'Remote callout servers are usually employed in an OPES framework to
either offload the OPES intermediary for better scalability or to provide
value-added services not available oneither the origin server or the OPES
intermediary'; scalability isn't specific to the use of a callout
protocol. Overall, though, this is the only motivation I can find for
using a callout protocol in the current OPES documents; it would be
useful to explore why executing services that aren't colocated with the
intermediary is necessary, and what scenarios it's appropriate/not
appropriate for.
Well, scalability might not be specific to a callout protocol (i.e. there
are many ways to improve scalability), but a callout mechanisms is one
way to improve scalability. For example, if you run ALL processing
intensive tasks on an in-path intermediary, this might soon become a
bottleneck when the number of user requests increases. If you now have a
callout mechanism, you can "outsource" those processing-intensive tasks
to remote callout servers to scale to an increasd number of users.
Yes. But when a single caching proxy became a bottleneck we found other
ways of clustering multiple caching proxies to fix that problem... I guess
the issue to be considered is whether one option scales better than the
other (and perhaps in which cases).
However, I agree with you that we need to do a better job in motivating
this, and, in particular, we need to provide some guidance explaining in
which scenarios this is appropriate and in which not. I had thought the
"Scenarios Document" might be a good place to do that.