Thanks for clarifying my understanding.
While I understand that the ASP market is having trouble handling simpler
usage scenarios than the ones I had outlined, I am not sure if technically it
is not possible to develop a feasible accounting and authorization mechanism.
Perhaps it is not possible - but it seems worth investigating. Many recent
research
activities such as the Iceberg project from UC Berkeley and the Dynamic
mediation work
from Stanford in fact make use of systems where "operators" (pluggable modules)
get
inserted into the data path (which may include operators to perform content
modification from
a web server). It occurs to me that OPES might provide a standardized and
scalable framework
for realizing such services.
I specifically see a lot of potential in OPES as the charter does make it quite
clear that we will define
an open and generic (beyond HTTP alone) interface (using protocols such as
ICAP and APIs for downloadable code) to allow third parties to provide
pluggable services. I was initially of the opinion that whatever OPES develops
can be put to use in the scenarios I had outlined, quite directly. The
motivation
for my earlier message was to get us thinking about scenarios quite different
from traditional CP-Content
Sink scenarios that is currently prevalent. I was getting the feeling that we
were sort of restricting our
view of the potential for OPES, and in the process come up with a restrictive
set of interface definitions.
Cheers,
Jayanth