Hi John--

	(I hope you don't mind if I also send this message to the Squeak list. It seems like something of interest to some others.)

> Do you recall where you read [that Mac OS X will not support MacTCP]?

	Yes; at http://developer.apple.com/macos/opentransport. About a third of the way down, on the right, it says "Mac OS X will support Open Transport APIs (but not 'classic' AppleTalk or MacTCP)."

> When is OS X due to come out, anyway?

	According to http://developer.apple.com/macosx, "Apple's new advanced version of the Mac OS will be available to developers in early 1999 and ship in the Fall of 1999."

> One question: Is your socket package a complete replacement for the one in
> Squeak (i.e., all new primitives based on Berkeley sockets)?

	Yes. Actually, I wrote it before you mentioned you were doing one. Unfortunately, I wasn't at liberty to mention mine at the time.

> If so, it might make sense to make it available as a Squeak "plugin" that we could try
> out for a while before deciding if it should replace Squeak's current socket interface.
> ...
> At the moment, I'm basically planning to just fix the accept() semantics so
> we can handle back-to-back connection requests and leave everything else
> alone.

	That sounds reasonable, especially since the current interface has people using it (and we can do plugins now :).

> Except for the problem with accept() (ha!), I don't have any problems with
> Squeak's current socket interface. I can see why someone familiar with
> the Berkeley sockets API would prefer it, of course.

	I have no particular attachment to the Berkeley interface (despite graduating from the institution from which it takes its name :). Indeed, I'm often tempted to dispense with using a C library for sockets altogether, and write the whole thing in Smalltalk (this was actually on my to-do list at one point in my previous project, when we had no sockets library for our weird hardware). I think the main benefit is that host libraries for it are widespread, so using it enhances portability in the meantime.

	However, as I mentioned before, I do prefer the way I factored the Smalltalk part. I prefer to keep external resources like sockets separate from the protocols which are conducted over them. My framework has "net correspondents" which use streams, and "net streams" which get their elements from external resources (not just sockets, but serial lines, files, MIDI instruments, etc.). I think it makes writing all clients and servers easier, but particularly those which make use of the added flexibility (eg., a network file system). Someone using the framework usually thinks about protocols, occasionally about streams, and almost never about sockets. I also prefer they way I handled a few other things like process synchronization.


	Ripping it out of our system (which forked from Squeak 1.13) is an interesting archaeological exercise. :)  Back to it...


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