I gather since most of you have not signed in on the Web Forum and the
deafening silence, that this group of people prefers to work via
electronic mail. If so, so be it.
Here is a first round of comments from this exercise.
More to come, along with the isl spec itself, sometime early next week.
- Jim
SCP comment:
1) Making the NG specification depend on any detail of the transport
session control protocol seems like a mistake to me. SCP exists to
avoid problems in TCP and existing network infrastructure; someday
other protocols may be more appropriate for HTTP than SCP over TCP. I
do not believe therefore that anything in SCP should be visible in the
NG spec itself, while something like SCP is clearly needed given TCP
as a transport. Some mapping from NG to SCP will need to be defined,
but the specifications should be kept completely separate.
As far as SCP itself is concerned, burning 8 bytes for
packet overhead seems excessive to me. At 9600 baud, think 8 milliseconds.
Too long, I think. We don't have that sort of latency budget to burn (at
least if you want to use the Web over any cellular modem system, which
are today even slower than that, though may eventually get to 9600 baud).
And I know of no 64 bit alignment requirements to run fast on any hardware or
datatype I've seen. Even if we want to keep the protocol naturally aligned,
the way to handle that is by rounding up at the end of a request to
whatever alignment is needed; no such requirement is needed for SCP or
NG's protocol elements.
Detailed comments:
a) NG needs some sort of multiplexing transport; whether by multiplexing
over a single TCP connection using SCP or not, how large individual chunks
of data, either inside of one TCP connection or not, needs to be
controllable; over a low bandwidth connection you would want
a smaller chunk size than over a high speed connection.
Presumably there needs to be a way to control the transport chunking size,
for whatever the transport is. While I don't necessarily expect an
application programmer to need to control this parameter, it is pretty
clear that the library does.
b) Question: the result from an InitializationResponse is boolean
named result. Is this just an indication that the initialization
succeeded?
c) Question: the client and server exchange ClientSupport and
ServerSupport fields in its initialization handshake messages.
How exactly are these fields used? Are both fields needed?
d) Question: How should Range be defined? It is not actually
defined in Simon's specification. For the moment, I defined
it to be two Long Integers (2 64 bit numbers).
d) Question: Should define-value, define-set, define-list, delete-value,
set-variable all be poly calls (array of definitions), to reduce
protocol overhead? I would argue they should be. One of the
experiences in mistakes in the X11 protocol design was that some
operations that could have been poly operations weren't (e.g. there
should have been a Poly-Polygon call in the protocol; there should
have been an XInternAtoms much earlier in the library and protocol, etc.,
and negotiation is one place where every bit needs to count.
e) Question: Cloning a context would seem to me to be useful; should we include
it here?
f) Question: How do I generate protocol transport errors for bad
Tags (duplicates)? This would be a buggy client, but the server needs to
indicate the bug back to a client in some form.
g) HTTPMessage does not have GetRequest and friends (Put, etc.) as an
Operation. Should it? I think so, from what I can see. What does messageId in
HTTPMessage do?
h) I would make contextID implicit in each message, along with the optional
tagged list, rather than part of HTTPMessage, if g) is true...
I don't see the point of having contextID, MessageID,
and a tagged list of changes as part of all operations; it seems to
me to be better if they were explicit arguments to each Operation type,
as I could forsee the possibility of extensions to HTTP that do not
necessary want or desire these fields in all messages, and don't want
to burn the bits.
i) Question: What happens in the case of out of order exection of requests,
if a change in the context is negotiated in the meanwhile?
The specification needs help in this area.
I am not sure that the general request/response ordering allowed by
out-of-order and interleaved is useful in general, and suspect it complicates
things more than necessary; I can see something like this being useful
in the semantics of Get, but suspect for other operations it generates
more trouble than it is worth. Feel free to convince me otherwise by a
plausible example. And once the web is used for more than just
getting information, other operations (rename, etc, which change
the name space) certainly depend on the order in which they are executed.
j) Question: a SessionID returned by GetResponse...
Is this the stream in which the data is being delivered in the SCP?
If so, (which I presume) see 1).
k) Question: USMARC metainformation standard? Pointer to it?
l) If I have several outstanding Get requests (say to the same
server for the same URL, for arguments sake,
to fetch multiple variants of the same object
(e.g. different languages or types)), the protocol needs some
what to correlate the resulting responses to the requests.
This can be handled by some sort of a sequence number associated
with each request (is this what messageID is for???). Such a sequence
number can be either implicit on the requestor's side (by having
the library and server increment a counter in sync; we did this
in the X protocol to save bits, but this complicates slightly
client and server implementation), or explicit.