On Tue, 29 Jun 2004, The Purple Streak, Hilarie Orman wrote:
I can't find the P draft nor the message giving the URL for it,
though
Yes, IETF silly [non]archival policy makes that difficult. You can get
the latest copy at: http://www.measurement-factory.com/tmp/opes/
I was going to resubmit the draft once we have the new charter. Should
it be done sooner?
The most important thing about the OPES language is that it support
a superset of regular expression matching functions that can be
composed efficiently by a special compiler.
I agree that regular expression matching would be nice, Fortunately,
REs should not affect the language specification much. That is,
language syntax and semantics are not going to be significantly
affected by support for regular expressions, unless we try really
hard. RE support should have no effect on the WG charter.
IIRC, somebody has objected to full RE support in P so the latest
draft only contains three basic primitives (contains, begins_with, and
ends_with). We should revisit RE issue once the WG charter is done.
The second most important thing is that it support composable,
reusable actions.
I agree. On one extreme, we have IRML-like approach where there is
virtually no room for human-friendly code composition and reuse. On
the other extreme, we have a programming language like Java or Perl
where the possibilities are endless. Since P implementations need to
be reasonably compact and secure, we most likely cannot afford
something like Java or Perl. If we can, we probably should not invent
a new language but just use Java or something!
I can't tell where these fall in the Rousskov a, b, c scope
definitions, and I would appreciate further amplication of them,
especially c,
I have posted some examples for (b) in response to Markus' email. They
should illustrate the difference between (1a) and (1b) better. There
were also a couple of threads about this last year if you want to go
really deep. REs would be supported at (1a) composition and reuse at
(1b). And please see below for more.
for writing modules for protocol-specific processor actions. I
cannot quite imagine how a language would support
protocol-nonspecific actions but could not support protocol-specific
actions.
Note that level (c) is about writing modules, not actions. Actions
would use those modules.
c) also an interface (language) for OPES processor
vendor or 3rd party to write protocol-specific
modules to be used when defining OPES processor
actions
Let me try to explain with a longer example. Suppose we define a
language that lets us write:
if (http.request.uri contains "xxx")
pornfilter.apply(request);
if (http.request.uri contains "yyy")
pornfilter.apply(request);
This is level (a) in my original scope classification. That's what P
already supports, more or less. If you get to level (b), you can have
something like:
action filterPorn(string badWord) {
if (http.request.usesChunkedEncoding())
return; // XXX: our filter cannot handle chunked requests
if (http.request.uri contains badWord)
pornfilter.apply(http.request);
}
...
filterPorn("xxx");
filterPorn("yyy");
The actual body of filterPorn() function would be more complex, of
course, justifying the encapsulation. The above are just simple
examples. Current P specification has very limited support for the
above, but some have argued that more support should be added.
If P supports level (c), you would be able to write something like
this (in P):
module HTTP;
use MIME;
use URI;
exports request, response;
class request extends MIME.message with {
...
URI uri;
...
boolean usesChunkedEncoding() { ... }
boolean expects100Continue() { ... }
...
};
...
As you can see the HTTP module written in P would have to deal with
low-level, usually protocol-specific manipulations of messages. It
will not, most likely, invoke any actions. However, actions will use
imported-from-module objects, functions, methods to do the adaptation.
In the extreme, one can probably even write a full-features adaptation
server (e.g., a virus scanner) in P if P supports level (c)
complexity!
Once again, I am skeptical that we should support level (c), at least
not in the first revisions of P.
Does this clarify?
Thanks,
Alex.