Hilarie,
I agree that WG primary focus should be on OPES services that
are executed "remotely" rather than integrated into the proxy code.
Such remote execution includes execution on the proxy box, of course.
My understanding is that jfc wants to use remote OPES services as
well. There seems to be no conflict here.
As far as I can see, the problem is that we (well, myself, at
least) are not sure what exactly jfc proposes as a potentially new use
case or application area for OPES. It is clearly not just giving any
single user application (e.g., a browser) an ability to talk OPES. The
issue seems to be related to entire user-side systems communicating
with OPES agents in yet unknown ways.
I sense that we may be talking about a Universal Callout
Interface for Web Services, but I do not have enough information to
conclude that. Otherwise, I would already argue that the discussion
should be terminated because no such interface can be built, not even
by XML fans.
Until we know exactly what jfc is after, I cannot say whether
those new use cases can be "the motivating examples for design
decisions" or not. I simply do not know what those new use cases are
and what new requirements they bring (besides IDNA conversion that
seems to be impossible in OPES framework). Perhaps others have a
better understanding.
Alex.
On Fri, 7 Mar 2003, The Purple Streak, Hilarie Orman wrote:
A proxy can be co-located with an application, using the same protocol
as if they were are different machines. However, this doesn't seem to
be a preferred implementation method, probably due to the overhead
involved. The more usual path is that someone defines an API that can
be implemented through direct subroutine calls, and then extends this
to work with RPC's for remotely located services. The advantage
being, of course, that one can write the callout service once and have
it run locally or remotely.
I think most browsers are already extensible, in their own ways, and
while it would be gratifying to have them switch to using a standard
method that is compatible with OPES servces, I don't see much reason
for that to happen. Our focus for the IETF is on services that benefit
from running remotely - because the services are more efficient when
amortized over many connections or some other engineering reason.
Surely there are other kinds of services that could run either
remotely or locally, or services that are best run locally, but these
will have to grow and flourish without diverting the attention of this
WG. It's fine to discuss such possibilities, but keep in mind that
they cannot be the motivating examples for design decisions.
Hilarie