Correspondents

Pennell's pennell at tiac.net
Sun Jan 10 15:50:51 UTC 1999


> 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).


How about "Network Protocol" ?  I think your framework is appropriate for implementing ITU
and vendor proprietary protocols such as Lego Mindstorms....

>> 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.
>

How tough will it be to extend this?  I'm working on SNMP and it uses ASN.1 encoding.

Your framework seems to be very stream oriented which is convient for most of the IETF protocols.
Have you
given any thoughts to protocols that are "message oriented"?  By message oriented, I mean ones that
use UDP
or use TCP with rigorous boundaries (imagine a TCP protocol that has a length field at the beginning
and you
don't know the length until you construct the message...).
It is sometimes handy to use a streaming protocol to construct the "network message".
At other times it is handy to construct the message field by field.  Transmission of the message
would normally
be under the (framework) users control.  In looking at your hierarchy, I suppose I could make these
"network messages" be the basic object that is streamed by a protocol specific stream.  Does this
sound right?

-david





More information about the Squeak-dev mailing list