socket.io

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

socket.io

Herby Vojčík
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.
Reply | Threaded
Open this post in threaded view
|

Re: socket.io

Philippe Marschall-2
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



Reply | Threaded
Open this post in threaded view
|

Re: socket.io

Herby Vojčík
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. :-(

Thanx, Herby
Reply | Threaded
Open this post in threaded view
|

Re: socket.io

Stéphane Ducasse
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.
>


Reply | Threaded
Open this post in threaded view
|

Re: socket.io

Philippe Marschall-2
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


Reply | Threaded
Open this post in threaded view
|

Re: socket.io

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: socket.io

Herby Vojčík
In reply to this post by Stéphane Ducasse
Stéphane Ducasse wrote
hi herby

what is specific with socket server?

Stef
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).
Reply | Threaded
Open this post in threaded view
|

Re: socket.io

Herby Vojčík
In reply to this post by Philippe Marschall-2
Philippe Marschall-2 wrote
On 10/11/2011 01:59 PM, Herby Vojčík wrote:
>> 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
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.
Reply | Threaded
Open this post in threaded view
|

Re: socket.io

Richard Durr-2
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:

Philippe Marschall-2 wrote:
>
> On 10/11/2011 01:59 PM, Herby Vojčík wrote:
>>> 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
>

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.

--
View this message in context: http://forum.world.st/socket-io-tp3891592p3894239.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.