Hilarie,
Proxylets can travel along the content path; whether or not they
are accepted depends on the policy of the boxes they pass
through. The boxes are concerned about privacy and
authorization and resource control.
Interesting. So proxylets are some kind of meta-data of the content
request (making sure they're not downloaded with every request).
As proxylets are fired upon rule matching, rules will also have to
either travel, be checked for accuracy and be inserted on
the fly or be pre-loaded on the boxes.
The model I had in mind was more restricted in that proxylets would have
to be "pushed" or "pulled" and installed on the OPES box, and were not
attached to the content request.
A typical kind of policy will be to honor agreements with a
CDN to let proxylets of certain types run as part of the
OPES environment. The CDN signs the proxylet or
provides an authenticated service for verifying a hash
of the proxylet. It gets to run, but with certain restrictions
that local adminstrators set. It can open connections
to sites that are part of the CDN, it can install authenticated
redirection policy to that CDN, it can access hit counts
and byte count information associated with that CDN.
Any kind or redirection right? So for example based on local or
global load balancing knowledge, a content provider proxylet could
do HTTP or DNS based re-direction for its own domain.
Perhaps we need to define explicit roles and trust
levels. Some proxylets will originate locally and
be fully trusted, others will be from partners with
mutual interests, others will be transient and subject
to low priority/low privilege.
May be we should start with Mark's comment on another e-mail:
"who the service is provisioned on behalf of" rather
than "who deploys the box".
Christian