At 9:15 PM -0500 11/7/99, Bijan Parsia wrote:
>So, the subjective and the objective reasons. I believe John Maloney
>hasn't moved on sockets because the project he was working on the second
>to last time sockets cropped up is still sucking up all his time.

Yep! But the end of the project is nigh. And, as a side-effect of
the project, we'll get Squeak Netscape plugins for the Mac and Win32.
(Mark Guzdial's been helping me test the Mac plugin and he is quite
happy with it so far.)


As far as the Mac socket implementation goes, I appreciate all the
news about Apple's plans w.r.t. sockets. I've read through their
Carbon (OS X) docs. As far as I can make out, Apple will support
the Open Transport API to sockets, which I believe is quite similar,
if not identical, to BSD sockets in functionality. Apple will no longer
support MacTCP, which is what the current Mac socket implementation is
based on. Thus, we will need to re-implement the Mac socket primitives
to the Open Transport API. In the process, we will also add support for
Andreas's BSD-style "accept()" primitive, and the Mac will finally be
able to handle back-to-back connection requests the way it should.

How much performance will you be able to get out of a Squeak-based
server on the Mac? I hope that will be limited only by the speed of
your hardware and the quality of the underlying OS socket implementation.
At OOPSLA, I heard some very impressive stories about the performance
of commericial Smalltalk-based web servers. I believe Squeak is capable
of similar high performance. Note that a typical commercial web server
under Unix involves spawning several Unix processes to handle the request.
Because the PWS does everything with lightweight Smalltalk threads,
the potential performance is even higher, I believe. However, I know
very little about web serving, and there may be good reasons for
structuring a web server as several processes, such as the ability
to have a front-end process that multiplexes incoming requests across
a number of back-end servers on different machines.

When will we convert the Mac network primitives to Open Transport? All
I can say at this point is that (a) we know it has to be done and
(b) it has to be done by the time OS X comes to desktop Macs. I'd
be interested in hearing from folks on the Squeak list who are
need this. I already know about Mark Guzdial.

Regarding Craig's web page on sockets at:
http://netjam.org/correspondents/advocacy.html. I don't buy his
arguments that having the VM report socket state changes via
two semaphores is intrisically better than a single semaphore. I'm
not saying the current Squeak socket primitives design is better;
it's just different from Craig's design. The two primitive sets
evolved in parallel when Interval's Squeak project was not sharing
their code, which isn't Craig's fault. However, at this point the Squeak
primitives have been implemented and debugged on quite a number of
platforms including the Sharp iCruise, and I see no reason to change
them unless they are either inherently flawed or unimplementable.
I don't believe either is the case. (The lack of "accept()" semantics
on the Mac is an implementation bug, not a design flaw, and that
will be fixed.)

What Squeak *could* use, I believe, is a simple and reliable SocketStream
implementation. I think that this has been implemented by various
people including Craig, Mike Klein, and probably several others.
The SocketStream abstraction can be built on top of the current socket
implementation. I think it would be a great service if someone,
perhaps Craig, would contribute an implementation of SocketStream. It
is also the true that some of our implementations for protocols such
as HTTP and FTP could stand to be overhauled or replaced. They were
done hastily and have served us well, but I think they could stand
to be refactored to make them more re-usable. I believe that some
of you (Ralph Johnson and others) have been talking about how to
best do this.

Cheers!

	-- John