Is there / planning a socket.io (server) support in Pharo? I am making suite of client-server application where I strongly consider socket.io as the communication layer; there is no problem with clients, but at the server-side, socket.io seems only to be supported by its native node.js (which is not bad, but I'd like to consider Smalltalks as well, Pharo being the first choice). Thanx, Herby
p.s. If you get this message second time, I am sorry, I got confused by the Nabble's messages. |
On 10/10/2011 09:47 PM, Herby Vojčík wrote:
> Is there / planning a socket.io (server) support in Pharo? I am making suite > of client-server application where I strongly consider socket.io as the > communication layer; there is no problem with clients, but at the > server-side, socket.io seems only to be supported by its native node.js Without async IO supporting WebSockets does not seem to make much sense. > (which is not bad, but I'd like to consider Smalltalks as well, Pharo being > the first choice). Thanx, Herby > > p.s. If you get this message second time, I am sorry, I got confused by the > Nabble's messages. I received it only once :-) Cheers Philippe |
I do not understand the rationale... "async IO" (more correctly, as Ryan Dahl often points, is "non-blocking IO", there is nothing async in node.js, it's single-threaded) is just the alternative model to "threaded, blocking IO". What does it have in common with sense of making WebSockets work? Nevertheless, it seems there is no support of server-side socket.io in Pharo, I conclude. :-( Thanx, Herby |
hi herby
what is specific with socket server? Stef >> On 10/10/2011 09:47 PM, Herby Vojčík wrote: >>> Is there / planning a socket.io (server) support in Pharo? I am making >>> suite >>> of client-server application where I strongly consider socket.io as the >>> communication layer; there is no problem with clients, but at the >>> server-side, socket.io seems only to be supported by its native node.js >> >> Without async IO supporting WebSockets does not seem to make much sense. >> >> ... >> >> Cheers >> Philippe >> > > I do not understand the rationale... "async IO" (more correctly, as Ryan > Dahl often points, is "non-blocking IO", there is nothing async in node.js, > it's single-threaded) is just the alternative model to "threaded, blocking > IO". What does it have in common with sense of making WebSockets work? > > Nevertheless, it seems there is no support of server-side socket.io in > Pharo, I conclude. :-( > > Thanx, Herby > > -- > View this message in context: http://forum.world.st/socket-io-tp3891592p3893938.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
In reply to this post by Herby Vojčík
On 10/11/2011 01:59 PM, Herby Vojčík wrote:
> > Philippe Marschall-2 wrote: >> >> On 10/10/2011 09:47 PM, Herby Vojčík wrote: >>> Is there / planning a socket.io (server) support in Pharo? I am making >>> suite >>> of client-server application where I strongly consider socket.io as the >>> communication layer; there is no problem with clients, but at the >>> server-side, socket.io seems only to be supported by its native node.js >> >> Without async IO supporting WebSockets does not seem to make much sense. >> >> ... >> >> Cheers >> Philippe >> > > I do not understand the rationale... "async IO" (more correctly, as Ryan > Dahl often points, is "non-blocking IO", there is nothing async in node.js, > it's single-threaded) is just the alternative model to "threaded, blocking > IO". What does it have in common with sense of making WebSockets work? Pharo only supports "threaded, blocking IO", so for each WebSocket (or long-polling, or forever i-frame) connection we need to have a Process lingering around. That makes Pharo less than ideal for building a socket.io server. Cheers Philippe |
In reply to this post by Herby Vojčík
On 11 October 2011 13:59, Herby Vojčík <[hidden email]> wrote:
> > Philippe Marschall-2 wrote: >> >> On 10/10/2011 09:47 PM, Herby Vojčík wrote: >>> Is there / planning a socket.io (server) support in Pharo? I am making >>> suite >>> of client-server application where I strongly consider socket.io as the >>> communication layer; there is no problem with clients, but at the >>> server-side, socket.io seems only to be supported by its native node.js >> >> Without async IO supporting WebSockets does not seem to make much sense. >> >> ... >> >> Cheers >> Philippe >> > > I do not understand the rationale... "async IO" (more correctly, as Ryan > Dahl often points, is "non-blocking IO", there is nothing async in node.js, > it's single-threaded) is just the alternative model to "threaded, blocking > IO". What does it have in common with sense of making WebSockets work? > > Nevertheless, it seems there is no support of server-side socket.io in > Pharo, I conclude. :-( > Sockets in Pharo are not blocking the whole VM. What they block is the process which working with concrete socket. But other processes can still run, while one waiting data / even from single socket. > Thanx, Herby > > -- > View this message in context: http://forum.world.st/socket-io-tp3891592p3893938.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko. |
In reply to this post by Stéphane Ducasse
It's socket.io (.io is important), a js library that abstracts server-push technologies into high-level API. What is specific to socket.io server is, well, to able to connect socket.io clients. And having an API similar to the original one (non-blocking "on event do callback" kind of thing). |
In reply to this post by Philippe Marschall-2
Thanx. That also answers the question if there is a project/plan for a socket.io server-side library (not, I assume) which I could reuse. So either write one (with knowing there will be lots of Processes involved), or not use Pharo for the server. |
I use socket.io with Amber and Node.js to build an App and that works rather beautifully. Maybe this may work for you, too.
On Tue, Oct 11, 2011 at 3:01 PM, Herby Vojčík <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |