Subject: protocol core now, transport/encoding later

From: Alex Rousskov <[email-masked]>
Date: Sun, 16 Feb 2003 22:59:31 -0700 (MST)

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

---

From: jfcm <[email-masked]>
Date: Mon, 17 Feb 2003 11:10:36 +0100

>points. We can then compare proposed solutions and fill in the

May I suggest that the OPES web master maintains a list on the site where 
we could list these ideas. Then we could discuss their aggregation into a 
minimum non conflicting list much more easily?

At this stage it could only be to paste them on an Excel page and to give 
them a number. The target would be first to see the one we really need, the 
ones wich means the same thing, etc.
jfc

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03