On 6 August 2011 00:56, Igor Stasenko <[email protected]> wrote: > On 6 August 2011 00:15, Noury Bouraqadi <[email protected]> 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.
