Re: P work in new charter

Folks,

this is getting far to complex for my taste and beyond the original 
scope. It moves functionality I would expect from a service itself 
into the rules language!

Rather than building all these fine-grained capabilities into the 
rules language itself, I would prefer a very simple rules langueage 
that allows me to invoke services - all the logic and more 
fine-grained rules are part of the service.

The whole reason we want to have callout servers is to move services 
out to a separate server. Are we now trying to move some of the 
processing complexity back into the OPES processor in form of a highly 
programmable, compelx rules language that allows "programming" of actions?

-Markus



Alex Rousskov wrote:

> 
> 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.