Taking off from Alex's list of current issues on P, pl find my comments
inline...
Alex Rousskov wrote:
Hi,
Here are some big P-issues that may be worth discussing at the
upcoming F2F meeting.
1. What information does the interpreter has
access to? Complete messages? Just meta-information?
Anything that is small? Do we define that,
does the module author, or does the ruleset
writer?
I think we should leave this decision of 'what is available' to the
module writer. For example, in the case of HTTP, just knowing the
request header (plus a preview of some data) may be sufficient for major
decisions, however, for SMTP, we may need to look at the complete body
(for example to figure out whether it is a SPAM). However, defining
interfaces between interpreter and module (see below) would help the
'ruleset writer' to use 'what is made available' in a predictable
fashion..
2a. Should this WG work on defining interface(s)
between P interpreters and module suppliers?
Situations where such an interface definition would help:
* Writing protocol agnostic P programs. For example, how does one write
a P program that restricts service requests from a specific IP?
if (request.clientIP() != "10.0.*")
reply.status(402);
If this is what you call as "meta-information", then we should enforce
that certain such parameters be accessible to the P module writer
irrespective of the protocol module used - specify exactly what this
meta information is ?
* Is it possible to make common objects such as "request" and "response"
could be made to have a certain specific structure across modules ?
2b. Should this WG work on defining interface(s)
between P interpreters and callout services?
I see some opportunity for some minimal standardization opportunities
for the modules that supply services too. From the example from the ID
in Appendix A,
service :=
Services.findOne("opes://local.net/add-lcl-content");
service.clientIp(request.clientIp);
We probably want this example to say:
service.setParam(clientIP, request.clientIP)
instead.
3. Is single-assignment worth keeping if we agree
that P deals only with small objects that are
cheap to copy?
I think it is nice to keep P as a single assignment language. Apart from
the things we discussed, I beleive this feature is also used to name
code segments. At present that is the only way to define 'functions' in
P - if we want to author modules using P.
The object.value() member may be used to pre-evaluate an object if
needed.
BTW, Do we retain the global scoping of all names in a P module? Or
should we add some scoping constructs too ?
4. Should more support for writing modules natively
in P be added? How much more support is needed?
If we define the mandatory module interfaces to be supported, I believe
that is sufficient. Remaining things may probably be left a specific
implementation. I beleive that native modules will mostly be to support
specific protocols while all other modules used by a P program would be
portable and will be written in P.
5. Should this WG document HTTP module for P?
As a part of HTTP Adaptation draft or a separate
document references from the adaptation draft?
6. If service invocation is just a module method
call, how do services return results? Should OCP core
document ways to return P-result via the OCP-result
structure? See also 2b.
Is it reasonable to insist that every service be wrapped up in a module
loadable from P interpreter? Since the module can have access to
request/response/message - common elements of a protocol, it is easier
to guanrantee consistency with the rest of the P program.
Consider the case:
Http := import "http://ietf.org/opes/rules/p/HTTP";;
if (Http.message.headers.have("Accept")) { /* Not executed */}
Services.applyOne(service)
if (Http.message.headers.have("Accept")) { /* Executed */ }
Thanks,
Alex.
Comments/thoughts welcome...
regards
Geetha
PS: Thanks Markus, for the reminder..