[Pharo-project] Questions about Ocean
1. why library does not serve as a factory for objects? I think it should, so one can write: library := MyLibrary new. socket := library createTcpSocket. socket connectTo: (library ipv4Address: 'x.y.z' port: 1000) I think it could simplify a lot of things. 2. what is OCNConversationTcpSocket and what its role? As to me it is unnecessary. I'd rather leave only single socket class in kernel. And for others, i think it would be better to use delegation instead of subclassing. So you will have: MyCustomRoleSocket (socket) -> OCNSocket (socketid, library) -> library with such encapsulation, you could ensure that you won't leak unwanted public/generic behavior outside of your model. While if you subclassing, it always takes everything as granted, and then it is unclear for user, what is safe to use and how. 3. Why OCNSocket keeps track its "state"? I think it would be better to always ask system about its state, because you never know for sure.. 4. error handling is below the waterline and needs to be addressed properly :) See the amount of error codes which connect() could produce. Where are they? Also, there is a lot of missing things for finer socket controls, like select(), poll(), fnctl() setsockopt() etc.. with all flags. So you have a lot to do :) 5. where i can put my code for NativeBoost backend of Ocean? 6. I understand that project is far from being complete, so don't treat my comments as an arrogant asshole. Just my thoughts, how it would be better to implement :) I created couple of classes and couple of tests (i could create socket, connect to remote host), but i stopping now, since of the above issues. Ideally, i would like to introduce you to NativeBoost and to see if you like it and if you can use it without my direct involvement (because it's already too much on my plate anyways ;) -- Best regards, Igor Stasenko AKA sig.
On 4 août 2011, at 17:25, Igor Stasenko wrote:
1. why library does not serve as a factory for objects?
I think it should, so one can write:
library := MyLibrary new. socket := library createTcpSocket.
socket connectTo: (library ipv4Address: 'x.y.z' port: 1000)
I think it could simplify a lot of things.
We aim at having multiple libraries and the socket choosing the default one, or leting the user choosing a different one. Still we didn't implement this protocol so far, though the bricks are there (see OCNNetworkLibraryProxyFactory)
2. what is OCNConversationTcpSocket and what its role? As to me it is unnecessary.
I'd rather leave only single socket class in kernel. And for others, i think it would be better to use delegation instead of subclassing. So you will have: MyCustomRoleSocket (socket) -> OCNSocket (socketid, library) -> library
TCP conversation socket is the socket that is used for exchanging data (sending / receiving). It's role is different from a TCP server socket which is there for establishing connections. Users of Ocean are not supposed to subclass these classes. If you want to implement a protocol, you need to go through a decorator pattern or a similar solution.
3. Why OCNSocket keeps track its "state"? I think it would be better to always ask system about its state, because you never know for sure..
Yes. But, so far we don't know how to do it. Can you get the state from the socket plugin? It should be possible in unix, though not trivial. Don't know about Windows.
4. error handling is below the waterline and needs to be addressed properly :) See the amount of error codes which connect() could produce. Where are they? Also, there is a lot of missing things for finer socket controls, like select(), poll(), fnctl() setsockopt() etc.. with all flags. So you have a lot to do :)
Ocean is far from complete. Still have already introduced some exceptions. Still, we don't want to have too many to avoid making the library too complicated. This is why we simplified the socket's life-cycle.
5. where i can put my code for NativeBoost backend of Ocean?
It seems that you are willing to introduce a new back-end for Ocean. So, you'll have to create a new library. You can take as an example, the plugin-library (OCNSocketPluginLibrary) as an example since it is the most advanced. Still, what you want to do is closer to the currently staled posix-library, based on Alien.
6. I understand that project is far from being complete, so don't treat my comments as an arrogant asshole. Just my thoughts, how it would be better to implement :)
Thanx for the feedback.
I created couple of classes and couple of tests (i could create socket, connect to remote host), but i stopping now, since of the above issues. Ideally, i would like to introduce you to NativeBoost and to see if you like it and if you can use it without my direct involvement (because it's already too much on my plate anyways ;)
Cool! We do like NativeBoost. We can pair program a bit together next time we meet. At least in the Esug confo @ Edinburgh :-) Noury http://car.mines-douai.fr/noury -- -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)
On 6 August 2011 00:15, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
On 4 août 2011, at 17:25, Igor Stasenko wrote:
1. why library does not serve as a factory for objects?
I think it should, so one can write:
library := MyLibrary new. socket := library createTcpSocket.
socket connectTo: (library ipv4Address: 'x.y.z' port: 1000)
I think it could simplify a lot of things.
We aim at having multiple libraries and the socket choosing the default one, or leting the user choosing a different one.
But this is orthogonal to my suggestion.
From user's POV, socket should support certain protocol. Period. Nobody interesting where it comes from, who creating it and where. Especially, that library "owns" sockets and only library knows how to manage them , so it is logical that library should serve as a factory for sockets (even if all libraries will use the same class, it is still better, since library have chance to control all aspects of its initialization before hanging it over to user). Because right now, if i issue OCNSocket new it answers a uninitialized socket in indefinitive (and therefore useless) state , and so you putting an obligation of proper object initialization outside of your framework , which is straight road to numerous gotchas and pitfalls.
Instead , if you let user to ask library to create a socket, then he will be confident that answered socket instance is well formed and ready for use.
Still we didn't implement this protocol so far, though the bricks are there (see OCNNetworkLibraryProxyFactory)
:)
2. what is OCNConversationTcpSocket and what its role? As to me it is unnecessary.
I'd rather leave only single socket class in kernel. And for others, i think it would be better to use delegation instead of subclassing. So you will have: MyCustomRoleSocket (socket) -> OCNSocket (socketid, library) -> library
TCP conversation socket is the socket that is used for exchanging data (sending / receiving). It's role is different from a TCP server socket which is there for establishing connections.
A server socket has to provide only few things to users (after it bound and started listening): - accept new connection - close The rest of socket protocol is useless and will produce the errors if you use it. So, instead of subclassing, a server socket can be a simple class, subclassed from Object and have only two!! methods , which makes life extremely easy for users, because they don't have to guess how to use it, and don't have to fear that some other components of library could send a wrong message (defined in superclass) to this socket instance which may lead to error. server := TcpServerSocket on: someOCNSocket.
Users of Ocean are not supposed to subclass these classes. If you want to implement a protocol, you need to go through a decorator pattern or a similar solution.
Yes, and i am asking, why these two subclasses are not decorators themselves? Because they are using only a subset of socket's functionality (you cannot connect once you already connected, you cannot send or receive data using socket which listening connections etc).
3. Why OCNSocket keeps track its "state"? I think it would be better to always ask system about its state, because you never know for sure..
Yes. But, so far we don't know how to do it. Can you get the state from the socket plugin? It should be possible in unix, though not trivial. Don't know about Windows.
4. error handling is below the waterline and needs to be addressed properly :) See the amount of error codes which connect() could produce. Where are they? Also, there is a lot of missing things for finer socket controls, like select(), poll(), fnctl() setsockopt() etc.. with all flags. So you have a lot to do :)
Ocean is far from complete. Still have already introduced some exceptions. Still, we don't want to have too many to avoid making the library too complicated. This is why we simplified the socket's life-cycle.
I know. Still, there has to be proper error handling. And it won't work without knowing exactly what happed (if function answers -1) , you should check errono etc.
5. where i can put my code for NativeBoost backend of Ocean?
It seems that you are willing to introduce a new back-end for Ocean. So, you'll have to create a new library.
I did that. But protocols are too fizzy right now, so i stop working on it for later, when i'll have a free time to do it. Meanwhile i will upload the library as a separate package to Ocean repository.
You can take as an example, the plugin-library (OCNSocketPluginLibrary) as an example since it is the most advanced. Still, what you want to do is closer to the currently staled posix-library, based on Alien.
yes yes
6. I understand that project is far from being complete, so don't treat my comments as an arrogant asshole. Just my thoughts, how it would be better to implement :)
Thanx for the feedback.
I created couple of classes and couple of tests (i could create socket, connect to remote host), but i stopping now, since of the above issues. Ideally, i would like to introduce you to NativeBoost and to see if you like it and if you can use it without my direct involvement (because it's already too much on my plate anyways ;)
Cool! We do like NativeBoost. We can pair program a bit together next time we meet. At least in the Esug confo @ Edinburgh :-)
Yes. We can :)
Noury http://car.mines-douai.fr/noury -- -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France
-5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)
-- Best regards, Igor Stasenko AKA sig.
On 6 August 2011 00:56, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 August 2011 00:15, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
On 4 août 2011, at 17:25, Igor Stasenko wrote:
1. why library does not serve as a factory for objects?
I think it should, so one can write:
library := MyLibrary new. socket := library createTcpSocket.
socket connectTo: (library ipv4Address: 'x.y.z' port: 1000)
I think it could simplify a lot of things.
We aim at having multiple libraries and the socket choosing the default one, or leting the user choosing a different one.
But this is orthogonal to my suggestion. From user's POV, socket should support certain protocol. Period. Nobody interesting where it comes from, who creating it and where. Especially, that library "owns" sockets and only library knows how to manage them , so it is logical that library should serve as a factory for sockets (even if all libraries will use the same class, it is still better, since library have chance to control all aspects of its initialization before hanging it over to user). Because right now, if i issue OCNSocket new it answers a uninitialized socket in indefinitive (and therefore useless) state , and  so you putting an obligation of proper object initialization outside of your framework , which is straight road to numerous gotchas and pitfalls.
Instead , if you let user to ask library to create a socket, then he will be confident that answered socket instance is well formed and ready for use.
Still we didn't implement this protocol so far, though the bricks are there (see OCNNetworkLibraryProxyFactory)
:)
2. what is OCNConversationTcpSocket and what its role? As to me it is unnecessary.
I'd rather leave only single socket class in kernel. And for others, i think it would be better to use delegation instead of subclassing. So you will have: MyCustomRoleSocket (socket) -> OCNSocket (socketid, library) -> library
TCP conversation socket is the socket that is used for exchanging data (sending / receiving). It's role is different from a TCP server socket which is there for establishing connections.
A server socket has to provide only few things to users (after it bound and started listening):  - accept new connection  - close
The rest of socket protocol is useless and will produce the errors if you use it. So, instead of subclassing, a server socket can be a simple class, subclassed from Object and have only two!! methods , which makes life extremely easy for users, because they don't have to guess how to use it, and don't have to fear that some other components of library could send a wrong message (defined in superclass) to this socket instance which may lead to error.
server := TcpServerSocket on: someOCNSocket.
or even better: server := TcpServerSocket listenOn: address using: someOCNSocket. like that, OCNSocket don't have to implement #bind: and #listen: protocol, only library has to do it, and only TcpServerSocket have to send those messages.
Users of Ocean are not supposed to subclass these classes. If you want to implement a protocol, you need to go through a decorator pattern or a similar solution.
Yes, and i am asking, why these two subclasses are not decorators themselves? Because they are using only a subset of socket's functionality (you cannot connect once you already connected, you cannot send or receive data using socket which listening connections etc).
3. Why OCNSocket keeps track its "state"? I think it would be better to always ask system about its state, because you never know for sure..
Yes. But, so far we don't know how to do it. Can you get the state from the socket plugin? It should be possible in unix, though not trivial. Don't know about Windows.
4. error handling is below the waterline and needs to be addressed properly :) See the amount of error codes which connect() could produce. Where are they? Also, there is a lot of missing things for finer socket controls, like select(), poll(), fnctl() setsockopt() etc.. with all flags. So you have a lot to do :)
Ocean is far from complete. Still have already introduced some exceptions. Still, we don't want to have too many to avoid making the library too complicated. This is why we simplified the socket's life-cycle.
I know. Still, there has to be proper error handling. And it won't work without knowing exactly what happed (if function answers -1) , you should check errono etc.
5. where i can put my code for NativeBoost backend of Ocean?
It seems that you are willing to introduce a new back-end for Ocean. So, you'll have to create a new library.
I did that. But protocols are too fizzy right now, so i stop working on it for later, when i'll have a free time to do it. Meanwhile i will upload the library as a separate package to Ocean repository.
You can take as an example, the plugin-library (OCNSocketPluginLibrary) as an example since it is the most advanced. Still, what you want to do is closer to the currently staled posix-library, based on Alien.
yes yes
6. I understand that project is far from being complete, so don't treat my comments as an arrogant asshole. Just my thoughts, how it would be better to implement :)
Thanx for the feedback.
I created couple of classes and couple of tests (i could create socket, connect to remote host), but i stopping now, since of the above issues. Ideally, i would like to introduce you to NativeBoost and to see if you like it and if you can use it without my direct involvement (because it's already too much on my plate anyways ;)
Cool! We do like NativeBoost. We can pair program a bit together next time we meet. At least in the Esug confo @ Edinburgh :-)
Yes. We can :)
Noury http://car.mines-douai.fr/noury -- -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France
-5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 6 août 2011, at 00:56, Igor Stasenko wrote:
From user's POV, socket should support certain protocol. Period. Nobody interesting where it comes from, who creating it and where
Exactly, this is why we will have constructor methods. So, creating a socket will be simply as : OCNConversationSocket new OCNConversationSocket connectedTo: 'someserverNameOrIP' port: portNumber But, we didn't implement these yet.
A server socket has to provide only few things to users (after it bound and started listening): - accept new connection - close
The rest of socket protocol is useless and will produce the errors if you use it.
Users of Ocean are not supposed to subclass these classes. If you want to implement a protocol, you need to go through a decorator pattern or a similar solution.
Yes, and i am asking, why these two subclasses are not decorators themselves? Because they are using only a subset of socket's functionality (you cannot connect once you already connected, you cannot send or receive data using socket which listening connections etc).
Yes. There is a lifecycle. We are aware of this problem. We write extensive tests for it. There are explicit exceptions to signal missuses, instead of a doesNotUnderstand. Anyway, we definetely have to pair-program a bit. Let's do it during the camp preceeding the ESUG conf. Noury http://car.mines-douai.fr/noury -- -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)
participants (3)
-
Igor Stasenko -
Noury Bouraqadi -
Stéphane Ducasse