Can you explain what you mean by "line speed" ?
Yup, this is not the correct term :) I was thinking of something like
"at the speed of today's caches/proxies". That means, when a
cache/proxy is able to handle N requests per second today, it would be
nice if it could handle a similar number with having OPES stuff
integrated (e.g. rule engine etc.).
Of course, we have to accept SOME performance impact when adding a
rule engine and the like (depending on the number of rues etc.) - the
question is how much performance impact people are willing to accept -
and this depends on where and how OPES boxes will get deployed
(therefore the need for a scenario document).
A proxy/cache is basically sitting in the "web path" of users, and
caches are already pretty busy just keeping up with the requests
coming in. Therefore, keeping the additional processing burdon away
from a proxy/cache and separating it out seems like a reasonable idea.
The difficulty is to find a good trade-off, i.e. how much processing
on the OPES device is acceptable (vs. granularity of the rules). One
suggestion is to do only header parsing on the OPES device, and do
body parsing in the service module. We now need to figure out whether
such an assumption would be acceptable or not.