Hi Bijan--

> There is a Squeak Central project for 1) doing the minimal to
> fix the broken socket stuff and 2) larger refactorings. But you
> know that :)

	Yeah, the swiki says that, but it seems Squeak Central has backed off from (2).

> I do have a concern, really two: 1) The streaming framework is
> rather a radical refactoring and, if adopted, would eventually require 
> updating large chunks of the system, yes?

	Only if one wanted to get rid of the old framework. I've done it once before already, when I originally wrote the new one (1996, Squeak 1.13). It took three days and wasn't difficult.

> And its rather different that the Blue Book classes yes?

	Not radically. The differences are in implementation; the message interfaces are very similar, and compatible. Perhaps the biggest difference is that "write-only"-ness is not expressed in the class factoring (I posit that it's not necessary).

> So really good docs would be required, porting becomes harder,
> etc.

	I intend to write good documentation. I have some already for the networking-related streaming stuff. I don't think porting becomes significantly harder, having converted an entire system already. I have compatibility messages for the transition.

> > > Can Correspondents easily be adapted to the official
> > > exception framework?
> >
> > It would be straightforward, but also a significant amount of...
> > tedious... work. Ah, restraint. :)
>
> But might be worth it anyway for portability to other Smalltalks?

	It might; I haven't decided how interested I am in doing it. It's just so depressing, after all the talk from Squeak Central about how they didn't particularly care about adhering to standards. I was shocked to see them attach so much importance to the ANSI standard, which goes beyond specifying interfaces into specifying implementation. (My exception-handling framework had ANSI support, by the way). So much for experimentation.

> For me, one fairly large concern with a Squeak networking system is
> reliability, performace, and scalability (the filestream classes get in
> here for typical applications)... 24x7 decent performance for small to 
> medium sized websites should be a no brainer... Add that in an
> ideal world (;)) the same image might also be running a ftp server,
> or a mail server, or be used as a client by someone, and things get a 
> bit messy. (Note: I don't think that a single Squeak instance *need* 
> handle such a heavy load easily, as a matter of course... In point of 
> fact, many people will use it this way...)

	My experience with the real-time Interval system leads me to believe this is very feasible. I intend to show this with netjam.org. It's up all the time, and I have full control over it. I plan to run many servers on it, in a single Squeak object memory.


	thanks,

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