Sig, Furthering a bad design practice does not illustrate an attempts to promote safe use of resources. If you knew that adding the behavior was a bad idea, why did you suggest it?
Server behavior: consider listening on ports and accepting connections. True, that is BSD socket behavior, but you are trying to have it both ways. You cannot complain about superset behavior that I might introduce and then later say that the current design is ok because it uses the same shotgun wedding approach as BSD (aka a superset interface). Taking your approach, nothing in Squeak would ever get fixed. In fact, "well, YOU can always do such and such in YOUR image" was the usual argument used to block change in Squeak. Something to think about. And yes, replacing the entire network system has crossed my mind. IPv4 and 6 are currently mixed into a big ball of mud (no offense to those working hard to add it, but it's not at all factored, and should be). I will hopefully soon be in a position to get network connections running across platforms, and I suspect that the errors reported some months ago will turn out to be due to the new sockets. Finally, we should have access to SSL sockets via OpenSSL. That might just drop in along side of the current socket system, but there might be room for a better solution, perhaps as an extension of Nile. Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 6:01 PM To: [email protected] Subject: Re: [Pharo-project] Socket>>socketStream 2009/10/30 Schwab,Wilhelm K <[email protected]>: > Sig, > > Exposing the streams is an interesting idea, and I think I could adapt it > should I ever want to back-port what I am doing to Dolphin (something I want > to keep open to allow an incremental escape from Windows). That might be the > answer. > > Subclassing socket to add stream protocol is a very bad idea IMHO - there is > too much overuse of inheritance in Squeak, and that would only add to it. > Right, it is BAD idea. I just illustrated the idea of keeping 1:1 correspondence between socket and stream at the extremum :) > Re UDP sockets, I could ask similar questions about the current mix of client > and server behavior in Socket. > what exactly you mean by server behavior? For what i see in Socket, its a wrapping aroung BSD-socket functionality, so you can send #accept using wrong socket as well as in C you can call accept() function and get similar results. Making a Socket interface behave similar to original sockets library, despite how bad or good the original design, having own reasons, which not even worth mentioning. So, i prefer to leave Socket to resemble the original BSD sockets functionality & behavior as close as possible, and if one wants a custom behavior, he can always create a subclass, or wrap it with own object, such as stream or whatever.. > Thanks! > > Bill > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Igor > Stasenko > Sent: Friday, October 30, 2009 3:54 PM > To: [email protected] > Subject: Re: [Pharo-project] Socket>>socketStream > > 2009/10/30 Schwab,Wilhelm K <[email protected]>: >> Hello all, >> >> What would be involved in adding a socket stream instance variable/accessor >> to Socket? Is that something you would support? So far, I created a shared >> dictionary (cleared on true startup) of sockets to streams, so once created, >> the stream is associated with the corresponding socket, and accessible from >> same using #socketStream. From there, I have #readStream and #writeStream >> accessors, which return the one stream - Dolphin separates them, and there >> is no reason to break the news to my code just yet. >> > > Err... what kind of stream you would answer for UDP socket, a socket which > inherently doesn't mean to support streaming capabilities? > The only reason why i would need to enforce 1:1 association of stream-based > socket with corresponding stream is to make sure that nobody constructs > multiple streams for using the same socket and in this way abuses it. But i > wouldn't care about that. There are numerous ways how to shoot in own foot, > and given case is very unlikely happen, unless you doing a really stupid > things, like exposing the sockets to different layers of your application > instead of exposing the streams which they should use. > > But from this perspective, wouldn't it be better to simply create a subclass > of Socket, which supports a stream protocol, so you enforcing the 1:1 rule > from very start and there is no way how to create one socket to many streams > association. > >> Bill >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
