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