Alex,
thanks for the input,
General remaks,
-- good questions that u raise, however, the questions should have been
answered in the protocol requirements draft, so i suggest that we start from
there.
abbie
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Monday, February 17, 2003 1:00 AM
To: OPES Group
Subject: protocol core now, transport/encoding later
Hello,
I would like to suggest that the selection of a
particular underlying protocol (HTTP, BEEP, SOAP, etc.) is
both not important and premature at this time. It is not
important because whatever protocol we come up with would be
possible to implement on top of any of those lower-level
protocols/APIs. It is premature because particular protocol
bindings and even performance would depend on minor protocol
details that are yet unknown.
The same is probably true about
XML-versus-text-versus-binary encoding decision. Any approach
will "work". We can pick the "best" later because the
selection will not (should not) affect the core protocol design.
I would also recommend to ignore things like
including/excluding version numbers or connection details
from certain messages. Those are just optimizations. There is
nothing to optimize yet. We all agree that the protocol
should be "simple" and "fast".
The following are some of the major decision points
that will affect the core, based on the discussion so far.
The items are taken from your messages, but I tried to
exclude questions that are already causing long discussions
while being, IMHO, of secondary importance. The order is
semi-random; these are all "major" items.
0) Whether there are clear/strict client-server roles or
whether it is possible for the server to send requests
to the client.
1) Whether the protocol is based on (request, response)
transactions or on possibly isolated messages (i.e., a
"request" may not demand/expect a response)
2) Whether a single request/message can solicit or
trigger multiple responses (e.g., OPES server expanding
an SMTP recipient alias into several addresses and
handling those addresses differently for the same OPES
request)
3) How exceptions are delivered to the other party (e.g.,
"I am not interested in seeing any more of this message")
4) How the "preview" feature is handled. What
the data-granularity of an OPES data transaction is (whole
message, header+tail, arbitrary range, arbitrary collection
of bytes?)
Did I miss any? It would be nice to have a more-or-less
complete list so that one can find/propose a simple protocol
covering all decision points. We can then compare proposed
solutions and fill in the details.
Thank you,
Alex.
--
| HTTP performance - Web
Polygraph benchmark www.measurement-factory.com | HTTP
compliance+ - Co-Advisor test suite
| all of the above - PolyBox appliance