Alex Rousskov wrote:
Text/* files are not that common, relatively speaking. The actual
reduction with the above technique would be less than 20% (by count)
and less than 10% (by volume). Here is a daily stats snapshot taken at
our IRCache proxies (www.ircache.net), for example:
Interesting.
For example, should P be able to block viruses that spread via simple
10KB HTTP POST requests? If yes, we give network operators a powerful
tool. If not, we tell network operators to rely on 3rd party modules
being available "soon enough" for each new virus.
I am not sure I understand this scenario. Are you suggesting that there
should be P module that provides a function to do the virus scanning?
And yet you did agree that allowing P modules to peek at small parts
of the body might be useful for things like content type determination
or, perhaps, blocking viruses in POST queries.
I do share your concerns about the overheads and complexities of body
handling in P. I am trying to find a flexible scheme that will cover
most cases with ease and leave some freedom for accommodating some
corner cases with effort.
One answer could be that something like findVirus(message.body) or
isGif(message.body) MUST be implemented as a service but may have a
function-call interface to P. We already have to deal with service
execution (something that is not well documented in P or IRML yet) so
we would not be adding much more complexity; we would just need to
document an interface where a service can return a value for P
interpreter to use.
Yes, I like that idea a lot. Conceptually, there is really not much of a
difference between a P module and an OPES service. But since we are
trying to define a framework for OPES services I think it makes a lot of
sense to provide functions such as isGIF or findVirus as OPES services.
Plus, this would also allow an OPES domain administrator to make a local
decision as to whether a service like isGIF should run locally on the
OPES processor or on a remote callout server. This should be transparent
to P programs, of course.
I think if we decide to go down this route, then it would be a natural
choice to restrict P module access to message headers while OPES
services can access the entire message. Of course, a utility service
like isGIF would only need to see the first few bytes of the message
body and would therefore be less expensive to invoke than a service that
needs to operate on larger parts of the message body. This could be one
criteria that determines whether or not a service is a good candidate
for local execution.
-Andre