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