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