Subject: RE: OPES protocol, pre-draft

From: jfcm <[email-masked]>
Date: Fri, 21 Feb 2003 15:03:44 +0100

Sorry, I though I had sent back to Hillarie and the list - I hate these no 
reply to the list - quite confusing to be forced to talk privately on a 
public place.

On 21:19 19/02/03, The Purple Streak, Hilarie Orman said:
>If you are going to allow the callout processor to have that much
>control, then it should be a fully general engine and be able to
>select the transport protocol, port numbers, application protocol,
>etc.  Heck, it should be able to open the connections itself.  I'd
>presented this concept at one of the pre-WG meetings, as an additional
>work item that might go onto a charter someday, but there was no
>interest.  It's still a fine idea, but not for this WG.

Hillarie,
my understanding of this WG is that IAB wants to have an http
on-the-flow massaging stable solution, what they name OPES.
Now I made clear that this is not only that I am interested in,
but in what I name ONES (open network extended services).

What I see from the mails is:

1. there is a clear understanding of what OPES are and how they
     could work in using SOAP, XML etc. CPU and line bandwidth
     consuming standard solutions. This is very interesting as it is
     a good consistent Internet response style with what is going
     around. It seems an exact, clear response to the IAB desire.

2. there is a smarter, pipe oriented, low cpu load approach with
     user interaction which corresponds to what I look for and which
     is actually like a network operating system.

Maybe should we not confuse them and protect OPES from ONES
in making two parallel propositions, one benefiting from the other?
So developers could pick one or pick the other, instead of
tricking OPES into ONES as they will probably want to do. And
as we start ourselves doing. Because I think that if we do not
respect the limitations imposed to OPES we will go all the way
down to standalone engines as you describe.

For example redirection could not be supported by OPES and
total by ONES?

>The very focused approach of in-the-flow content adaptation that we have
>now is a good one, and it reflects current practice and engineering
>principles that are known to work very efficiently.  In this model,
>the communication control point is the OPES box, and it is not slaved
>to the callout servers.
>The OPES rules can be used to change the source
>and destination, and the OPES box is the most efficient place to accomplish
>that function.

This is a problem to me as I think dispatcher/service. This means that
the OPENS box is a dispatcher (rules filtering) with a separated
simple service? Or do you mean that the intermediary service is
part of the rules? This has an impact on protocol because the same
services could also be supported by a server should it become too
heavy, etc..

>Spreading the essential control functions over a set of callout servers sets
>up all kinds of configuration nightmares that will hinder adoption of
>OPES.

May be you are right. We want to have a transportation solution.
IAB asked for a bicycle. Some think about a car. Better to think
about a bicycle and about a car, rather than to try to build an
Harley Davidson?
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 21 Feb 2003 11:59:30 -0700 (MST)

On Fri, 21 Feb 2003, jfcm wrote:

> Sorry, I though I had sent back to Hillarie and the list - I hate
> these no reply to the list - quite confusing to be forced to talk
> privately on a public place.

<offtopic>Better to be forced to talk privately than publicly! But you
should not blame the mailing list organization -- blame your mail
agent instead, for not auto-filling both TO and CC headers :-).
</offtopic>

>      is actually like a network operating system.

Perhaps it is just me, but I am still not quite sure what ONES is or
should be. Could you please give two very specific, real-world ONES
examples? Clearly, if there is a smarter, lower-load architecture we
should at least consider it!

Thank you,

Alex.