Re: P work in new charter

Alex Rousskov wrote:

> 	The two big P-questions that we may need to answer in the new
> charter are:
> 
> 	#1. How deep does P reach? (P scope)
> 
> 	    a) just an interface (language) for rule writer
> 	       to use when configuring/selecting existing OPES
> 	       processor actions
> 
> 	    b) also an interface (language) for OPES processor
> 	       vendor, administrator, or 3rd party to write
> 	       generic (parameterizable) OPES processor actions
> 
> 	    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

Can you give practical examples of (b) and (c)?

What would be the benefits of having one language that can do all 
these, as opposed to having one language for (a) and another for (b) 
and/or (c)? To me, these things seem sufficiently different...

I'm pretty reluctant to go beyond (a), which was the original intent 
of the rules language.

> 	#2. How deep does our charter reach? (WG work scope)
> 
> 	    a) just the core language (like C without the standard
> 	       library or standard template library)
> 
> 	    b) also HTTP and SMTP module interfaces for selecting
> 	       or writing HTTP- and SMTP-related actions (like
> 	       the standard C libraries interfaces)
> 
> 	    c) also an interface between P interpreters and
> 	       module/services suppliers? (like Unix or MS
> 	       library loading conventions)

I would consider (a) and (b) in scope.

> Note that the answer to the first question determines how much work we
> would have to do when documenting language core. If we limit P scope a
> lot, we will have to do less work. On the other hand, if we pick wrong
> scope, it may be insufficient or too complex to interest vendors in
> supporting it.

The problem to be solved with the rules language is "how do I tell the 
OPES processor which services have to be executed on what messages" - 
a solution to that problem alone would bring us a big step forward and 
would be considered valuable, I assume.

> Is there a possibility to define a very simple P core while allowing,
> in principle, feature-rich extensions to write P modules and such? Not
> sure, but that could be the ideal approach. Kind of like Java applets
> versus Java applications, but even more extreme. On the other hand, if
> the core is really simple/basic, does it make sense to extend it at
> all? Instead, it may be better to start from scratch for (a), (b), and
> (c) in question #1 above!

I would suggest to phrase a new charter to include (1a) and (2a,b). 
This does not preclude us from looking at the approach you mention 
above, but it allows us to focus on the essential part in case it 
turns out to be too complex.

> FWIW, IRML, if further developed, would probably fit (1a) and (2b).

While I agree (and while I personally like IRML :), we made a decision 
earlier to go with the "P" approach, and I would hesitate to revise 
that decision without a really strong reason.

-Markus