Hi Ralph--

> Here are my reactions...

	Thanks for taking a look at this rough stage! I hope you don't mind me including the Squeak list on this message. Also, please forgive me if I say things you already know. :)

	To avoid confusion with "protocol" in the traditional Smalltalk sense, I'll use "IETF protocol" as a blanket term for things like HTTP. "IETF" is of course the "Internet Engineering Task Force", the specification coordination body (http://www.ietf.org).

> What does serveAtPort:queueSize: do? None of the comments 
> seemed to say; they just either repeated the name or the 
> implementation, and were superfluous.

	Hmm, sorry. That message asks the receiver to start listening for client connections on a port, and to provide a queue where clients may wait to be connected (instead of being refused a connection). For example, if a Server has a queue size of three, and the VM thread which accepts connections is busy accepting client A, then if clients B, C, and D try to connect, client D will be refused. I tacitly assumed that "queue size" was already meaningful to the reader as a Berkeley sockets programming concept, which I shouldn't do...

> I can tell that a Correspondent has a stream, and that messages
> sent to it cause it to do something with its stream.  Is a
> Correspondent an object that corresponds to a protocol
> and that ensures that the stream speaks the protocol?

	Roughly... an instance of a concrete subclass of Correspondent knows all about how to converse via a particular IETF protocol. The stream it uses is a generic NetStream, with only a simple stream interface (regardless of the IETF protocol statements being sent over it, or the transport mechanism it uses).

> I would think that an HTTP client would have operations like
> "get URL" and "put URL with data".  Are those commands?
> What is a server command?  A string?  A number? An instance
> of Command? I assume an HTTP client translates get and
> put into commands.

	Yes. So far, "commands" are just Strings. E.g., 'GET' and 'HEAD' from HTTP. All the popular protocol specifications we've dealt with so far (see http://www.rfc-editor.org) use simple ASCII. I'd like to do interesting things with distributed objects later.

> That must be why it doesn't implement next, but just nextPutAll:.

	Actually, that message is for public convenience. It lets an application write things via a Correspondent. A Client will write to its remote server, and a Server will broadcast to all of its remote clients (I forgot to include Server>>nextPutAll: in the release, by the way).

> Its stream is used to get data from the server, but not to send
> data to the server.

	Actually, it's used for both; so...

> If you were building a web browser, you'd want to fetch a URL
> and turn it into a stream. Can you do that?  Can a web browser
> parse the HTML at the same time while the page is still being
> loaded?

	...yes. NetStreams can read, write, peek, and skip forward and backward.


-C



--
Craig Latta
composer and computer scientist
craig.latta at netjam.org
www.netjam.org
latta at interval.com
Smalltalkers do: [:it | All with: Class, (And love: it)]