Stef, Noury, Thanks for doing this, and for the preview!
Sometimes being a good friend means getting tough, and it's time for that. You are doing a great job of writing up how to create poorly designed socket applications. They are poorly designed because of what we inherit from Squeak. Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server. Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user. Nothing should block in either case except the calling Smalltalk Process. If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread. IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works. At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options. Bill ________________________________________ From: stephane ducasse [stephane.duca...@free.fr] Sent: Monday, August 30, 2010 2:50 PM To: Schwab,Wilhelm K Subject: Fwd: [Pharo-project] Sockets in Pharo CollaborActive Book Begin forwarded message: > From: Stéphane Ducasse <stephane.duca...@inria.fr> > Date: August 29, 2010 11:09:50 PM GMT+02:00 > To: DeNigris Sean <s...@clipperadams.com> > Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book > _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
