[Pharo-project] Socket>>socketStream
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. Bill
2009/10/30 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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. Re UDP sockets, I could ask similar questions about the current mix of client and server behavior in Socket. Thanks! Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 3:54 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream 2009/10/30 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/10/30 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 3:54 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream
2009/10/30 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 6:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream 2009/10/30 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 3:54 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream
2009/10/30 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/10/31 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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?
because, as to me, what you are proposing is equivalent to it. In smalltalk you can enforce the correct usage of provided functionality only by means of provided behavior.
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).
we have what we have. :) If you'd were writing own library for network communication which directly speaks with hardware (like in SqueakNOS), then you are free to do it differently. But Socket implementation depends on underlaying socket library, adopted by wide range of OSes working with wide range of hardware. It is good that we having something in common and don't need to invent or implement it from scratch. And despite how good or bad it is, it allows us to write portable software, including smalltalk, unless you refactor Socket class :)
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.
if there will be fix or extension in original socket library, only then we should consider synchronizing Socket class with it.
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.
as long as you are using same library (sockets), i see not much reasons why we would need to drastically refactor the stuff. Because, with whatever code will wrap it, you end up using same system calls which expecting same argument types & returning same results. So, instead of 'better wrapper', we should expose these calls to language, as close as possible to original and this is the main role of Socket class. Then anyone is free to use them as he likes to. This is what i meant by talking about 'own subclass' and this is why i think that Socket class is bad place for refactory. My point is, that if you writing own library/classes, which having virtually no dependencies from other frameworks, then you are free to do it in any way you like to. But if your goal is to expose the functionality of existing library (such as sockets), then instead, you should be very pedantic and do it as much as close to original, despite how good or bad it is. Then you are opening doors to people who already used this library before, but in another environment/language. -- Best regards, Igor Stasenko AKA sig.
Sig, An OO layer on top of procedural software does not have to be tied to the limitations of the procedural software, and in general should not be. You make refactoring of Socket sound like it can only be done by a complete slash and burn, when in fact it could be as simple as exposing behavior where it makes sense. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 30, 2009 7:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket>>socketStream 2009/10/31 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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?
because, as to me, what you are proposing is equivalent to it. In smalltalk you can enforce the correct usage of provided functionality only by means of provided behavior.
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).
we have what we have. :) If you'd were writing own library for network communication which directly speaks with hardware (like in SqueakNOS), then you are free to do it differently. But Socket implementation depends on underlaying socket library, adopted by wide range of OSes working with wide range of hardware. It is good that we having something in common and don't need to invent or implement it from scratch. And despite how good or bad it is, it allows us to write portable software, including smalltalk, unless you refactor Socket class :)
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.
if there will be fix or extension in original socket library, only then we should consider synchronizing Socket class with it.
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.
as long as you are using same library (sockets), i see not much reasons why we would need to drastically refactor the stuff. Because, with whatever code will wrap it, you end up using same system calls which expecting same argument types & returning same results. So, instead of 'better wrapper', we should expose these calls to language, as close as possible to original and this is the main role of Socket class. Then anyone is free to use them as he likes to. This is what i meant by talking about 'own subclass' and this is why i think that Socket class is bad place for refactory. My point is, that if you writing own library/classes, which having virtually no dependencies from other frameworks, then you are free to do it in any way you like to. But if your goal is to expose the functionality of existing library (such as sockets), then instead, you should be very pedantic and do it as much as close to original, despite how good or bad it is. Then you are opening doors to people who already used this library before, but in another environment/language. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Igor Stasenko -
Schwab,Wilhelm K