Hi,
Please find my comments on the internet draft on P language below. It
also has some suggestions for new constructs for the 'P' language.
* Section 2, Syntax: While several operators are listed out along with
their precedence, it may be helpful to support the commonly used
parenthesized expression with an additional rule :
expression = '(' expression ')'
* Section 3.3 Operators: Even I did not like the use of case to
distinguish operator attributes (such as case sensitivity) eg: EqualS,
ContainS.
On the contrary, I think it would be nice to have the operators
themselves case insensitive, so EQUAL = equal = EquaL . Use of equal_i
and equal_s is preferable.
* Section 3.6 Assignments: I like the single assignment approach of P.
However, I feel the need for a few additional statements (or Core
services) to manipulate the scope of a name - for eg: 'kill' a name in
the current scope. Some uses of such a construct would be:
** We could essentially acheive a private name space when modules are
imported. This can be done by killing all the private variables from a
module before exiting the module ( if the module is written in P).
** This is will also help in reducing name clashes that may result in
use of same names from 2 different modules. The case of
smtp := import "..";
http := import "..";
kill SMTP.message ;
meth = message.method;
** "kill moduleName " could unload a module too.
** Another useful scope manipulation statement would be something like
"inline Http" (or "use Http") statement that makes references to be
resolved in the context of module Http (instead of the default
behaviour of resolving in the context of *all* the modules being
imported)
* Section 4.1: Interpreter-module interface.
** I think we should at the minimum specify a minumum interface that
must be supported by a module, such as - isDefined("membername") and so
on - which could typically be provided a default behaviour by the
interpreter (based on the semantics of the import statement).
** There is also a need to specify the characterisitics of the service
being returned by the imported module. (or give a reference to where
this info is available)
*** What is the interface expected of this service? Is it a proxylet?
Web service?
*** How does it get access to the request/response being manipulated?
*** What is the semantics of the Services.applyone(service)? Will it
modify the response/request to be used further on?
*** Will the interpreter employ the call-out protocol at this point? If
so, does it send the response or the request? For example, in the ICAP
case, is it RESPMOD or REQMOD?
** How does one specify the vectoring point (equivalent of 1,2,3,4 in
IRML)?
* Section 4.2: In my opinion, the case of module being a P program needs
to be further thrashed out. For example: which are the valid members of
a module defined using P. All the names in the program ?
* Finally, with my small exposure of writing an IRML parser that
generates a python rule engine, I feel this language 'P' is very well
suited to be implemented in Python. In fact, if we excuse the syntactic
changes, P can straight away be expressed in Python! and that's nice.
Hope this helps.
Incidently, are there any efforts underway to implement this language?
Thanks and regards
Geetha
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Open Pluggable Edge Services Working Group
of the IETF.
Title : P: Message Processing Language
Author(s) : A. Beck, A. Rousskov
Filename : draft-ietf-opes-rules-p-01.txt
Pages : 30
Date : 2003-9-22
P is a simple configuration language designed for specification of
message processing instructions at application proxies. P can be used
to instruct an intermediary how to manipulate the application message
being proxied. Such instructions are needed in an Open Pluggable Edge
Services (OPES) context.