Noury, First, please don't assume that you have to change course just because we offered to help. If you are close to having a major improvement, then it might be best to just power through it. If there are things holding you up, we might be able to help there.
Using Alien concerns me a little, as the last time I checked, it was not available on Linux?? Failure to support Linux would be a complete show-stopper for me. Regardless, I would like to see your code as I have read some comments suggesting that Alien is cumbersome to use; you might show me that all is well. My interest in Alien is primarily to support callbacks for numerical analysis. So far, I have been adding functions to a shared library, which is easy enough, ultimately translates formulas using C++ (which is better at it than Smalltalk), likely makes things go faster than they would with Smalltalk in the loop, but is far from elegant. Until Alien exists on Linux, it does not exist :( Back to sockets, if the current situation were to stand, for whatever reason, I would consider tackling the problem using a plugin to get OS threads, and use them to achieve the non-blocking operation that is essential for interactive software. In short, everything blocks its calling Smalltalk Process; nothing blocks the entire image. Hopefully you recognize that a server listening with timeouts is hideous design; just start and stop the server as needed, and it should be harmless to the image. If the server is not harmless to the image, it needs to be fixed. Clients having timeouts isn't much better. If you want to add helper methods with timeouts, who am I to tell others what to do, but we must not force timeouts on clients because there is no correct answer to how long something should wait, so we should not look for one. What we should do is make sure that we never block the entire image, and let people make their own decisions. Why would I consider a plugin? In large part because there are hints that I would find examples to follow, and because OpenSSL has a very cumbersome non-blocking interface, at least that was my impression of it. A plugin that I would write would hopefully support TCP and OpenSSL sockets, and hopefully IrDA. Running those things on OS threads and signaling semaphores in the image is likely to be simpler than working out the details of non-blocking calls in the separate worlds - I think. I can understand why you are not thrilled about creating a plugin. The sad part of this is that the current sockets system appears to demonstrate all of the essential pieces to make something that really works; it just hasn't been done. On attempting it, I would no doubt run across things that you found and led you to create a new system. Creating something new allows it to coexist with the current code until it is ready, at which point it could be integrated into Pharo. Thanks for working on it. Is the code on Squeaksource representative of your current progress? Please do not let my interest slow your efforts. If you are indeed doing all of the right things, it might be that my efforts should be directed toward getting Alien going on Linux. It might also be that I can be of most help simply by doing to your code what I did to DCOM long ago. Our network was a harsh landscape, and I got fairly good bringing code to its knees on intranets. This involves creating forked processes doing active communication across a hub that coincidentally gets unpowered w/o warning :) Threads must block or give errors, but the images must continue to be responsive and other threads must run as expected. Until we reliably pass that test, this is all just a game. Bill ________________________________________ From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Noury Bouraqadi [bouraq...@gmail.com] Sent: Saturday, September 04, 2010 5:31 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book Hi Bill, On 1 sept. 2010, at 05:59, Schwab,Wilhelm K wrote: > The deeper question is whether we want to document how things are, or they > they *should be* - which is VERY much different from the eventless and > timeout ridden design that we have now. It desperately needs to be > redesigned. > I agree that the current status of the networking libraries is horrible. But, to learn the current status and think of the alternatives, I felt the need to understand how thinks work now. As Stéf said, Luc and I started the Ocean project. Thanks you Bill and to Guille for your proposal to help. It's a pitty that you don't attend to the ESUG conf (Your names are not on the registrations list) otherwise we could discuss this better. Cause Luc and I will give a short presentation describing the current status of Ocean and where it is headed. Now, we need to think how to split the project in order to have other contributions. Note BTW, our goal is to have a low-level Pharo wrappers of the networking facilities of the OS. We started using Alien to avoid using a plugin and ease portability. Once we get this low-level layer, we'll go on and use it in an OOP middleware like rST and UbiquiTalk. Which is after all, the right level to work with since we want to deal with objects and message sends. A direct use of Sockets isn't really OO most of the time. Noury _______________________________________________ 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
