Another WS subprotocol

#1

Hi there,
Fellas I’m writing to first say thanks for this amazing project.

Second, I would like to contribute with the community, I implemented a client library for the popular subprotocol Socket.IO (which some prefer to work with), on top of the AutobahnAndroid library.

https://github.com/magnux/IOBahn

This is a very early work, with only some hours of work, but thanks to its solid base, is a very promising library.
I like a lot the WAMP, but you know, now we have another flavor of WS.

Thats all folks.

Regards,

Alejandro

0 Likes

#2

Hi Alejandro,

great that you are reusing AutobahnAndroid for your project! We should probably make AutobahnAndroid more visible as the most mature WebSocket implementation - independent of it’s WAMP functionality. Curious: did you consider any other Android WebSocket implementation? I only know weberknecht, and that seems to be unmaintained and only implements Hixie-76.

That said I’m not sure I can follow the project goals fully … Socket.IO provides several fallback mechanism for “plain bidirectional messaging”. I does not provide RPC or PubSub messaging patterns. When Socket.IO can use WebSocket as a transport, it’s subprotocol does not add anything significant to WebSocket: it’s just plain bidirectional messaging.

Honestly, when WebSocket is available, I can’t see the point of using Socket.IO

Cheers,
Tobias

···

Am Freitag, 29. Juni 2012 04:43:57 UTC+2 schrieb Alejandro Hernandez:

Hi there,
Fellas I’m writing to first say thanks for this amazing project.
Second, I would like to contribute with the community, I implemented a client library for the popular subprotocol Socket.IO (which some prefer to work with), on top of the AutobahnAndroid library.

https://github.com/magnux/IOBahn

This is a very early work, with only some hours of work, but thanks to its solid base, is a very promising library.
I like a lot the WAMP, but you know, now we have another flavor of WS.

Thats all folks.

Regards,

Alejandro

0 Likes

#3

Hi Tobias,

Thanks for writing me back.

I did considered using other implementation of WebSocket for Android: https://github.com/koush/android-websockets.

This implementation also has an interface for Socket.IO. However, I was not comfortable with that implementation, I’ve tried it, and it was a bit unreliable under high load (10 messages per sec) or big messages (over 500KB).
Also, I’ve read the code of android-websockets, and I think it needs a lot more of work to get to the maturity AutobahnAndroid has (Also only implements Hixie-76 btw).

Some months ago I’ve tried the AutobahnJS library using WAMP and it was great, so when this project came, and I was looking for alternatives for and Android client library I thought: why simply not implement this(socket.io) over that(autobahn)?, an I did so.

About using Socket.IO, I agree with you, when WebSockets are available, there’s no point in using it. However, some projects require us to support platforms where WebSockets are not available, and Socket.IO is really flexible in that, requires little to none adaptation of code to work even in the oldest browser. Also, this project is being developed over node.js related technology, so using socket.io seems the most natural option to use.

By the way, Socket.IO doesn’t implement PubSub, but it is really close to it: when clients connect, they can join rooms, and then the server can broadcast messages to such rooms. This behavior is almost PubSub, with the difference that client is not required to do a handshake to listen to a channel (room), instead, the server puts the client where it wants, and sends the events(messages) when it wants, after that, if the client has a handler for that type of message, it handles the message, if not, simply ignores the message. It’s like a loose PubSub, where no strict behavior of client and server is expected. Perhaps, this kind of behavior has sense when the clients are from a wide range of platforms, and maybe some of them are only observing, polling the information.

All that aside, If I could choose what the clients should use, I would choose only android and chrome, so I could have fun programming and they could get the best user experience.

The only client library I think that Autobahn is missing, is the native IOS library. I know AutobahnJS works on IPhones, but some applications require a native client, and something like a service running in background is the best way to do it.

Anyway, AutobahnPython is a great server, and AutobahnAndroid is a great client library, and I would use it for future projects if the circumstances allows me.

Cheers,

Alejandro

···

On Sunday, July 8, 2012 10:29:42 AM UTC-4:30, Tobias Oberstein wrote:

Hi Alejandro,

great that you are reusing AutobahnAndroid for your project! We should probably make AutobahnAndroid more visible as the most mature WebSocket implementation - independent of it’s WAMP functionality. Curious: did you consider any other Android WebSocket implementation? I only know weberknecht, and that seems to be unmaintained and only implements Hixie-76.

That said I’m not sure I can follow the project goals fully … Socket.IO provides several fallback mechanism for “plain bidirectional messaging”. I does not provide RPC or PubSub messaging patterns. When Socket.IO can use WebSocket as a transport, it’s subprotocol does not add anything significant to WebSocket: it’s just plain bidirectional messaging.

Honestly, when WebSocket is available, I can’t see the point of using Socket.IO

Cheers,
Tobias

Am Freitag, 29. Juni 2012 04:43:57 UTC+2 schrieb Alejandro Hernandez:

Hi there,
Fellas I’m writing to first say thanks for this amazing project.
Second, I would like to contribute with the community, I implemented a client library for the popular subprotocol Socket.IO (which some prefer to work with), on top of the AutobahnAndroid library.

https://github.com/magnux/IOBahn

This is a very early work, with only some hours of work, but thanks to its solid base, is a very promising library.
I like a lot the WAMP, but you know, now we have another flavor of WS.

Thats all folks.

Regards,

Alejandro

0 Likes

#4

Hi Alejandro,

just a short comment:

Yes, I totally agree, AutobahniOS is clearly missing .. on iOS, there is a mature WebSocket implementation (SocketRocket), but sadly nothing as powerful
as Jackson (for streaming and object mapped JSON processing).

Plus, I haven't written a single line ObjC in my life;)

Anyone interested in helping?

Regarding node: you could implement a WAMP server on node.js of course ..

Anyway, thanks for the compliments! Spread the word on Autobahn;)

Cheers,
Tobias

···

Am 09.07.2012 00:30, schrieb Alejandro Hernandez:

Hi Tobias,
Thanks for writing me back.

I did considered using other implementation of WebSocket for Android:
https://github.com/koush/android-websockets.
This implementation also has an interface for Socket.IO. However, I was
not comfortable with that implementation, I've tried it, and it was a
bit unreliable under high load (10 messages per sec) or big messages
(over 500KB).
Also, I've read the code of android-websockets, and I think it needs a
lot more of work to get to the maturity AutobahnAndroid has (Also only
implements Hixie-76 btw).

Some months ago I've tried the AutobahnJS library using WAMP and it was
great, so when this project came, and I was looking for alternatives for
and Android client library I thought: why simply not implement
this(socket.io) over that(autobahn)?, an I did so.

About using Socket.IO, I agree with you, when WebSockets are available,
there's no point in using it. However, some projects require us to
support platforms where WebSockets are not available, and Socket.IO is
really flexible in that, requires little to none adaptation of code to
work even in the oldest browser. Also, this project is being developed
over node.js related technology, so using socket.io seems the most
natural option to use.

By the way, Socket.IO doesn't implement PubSub, but it is really close
to it: when clients connect, they can join rooms, and then the server
can broadcast messages to such rooms. This behavior is almost PubSub,
with the difference that client is not required to do a handshake to
listen to a channel (room), instead, the server puts the client where it
wants, and sends the events(messages) when it wants, after that, if the
client has a handler for that type of message, it handles the message,
if not, simply ignores the message. It's like a loose PubSub, where no
strict behavior of client and server is expected. Perhaps, this kind of
behavior has sense when the clients are from a wide range of platforms,
and maybe some of them are only observing, polling the information.

All that aside, If I could choose what the clients should use, I would
choose only android and chrome, so I could have fun programming and they
could get the best user experience.
The only client library I think that Autobahn is missing, is the native
IOS library. I know AutobahnJS works on IPhones, but some applications
require a native client, and something like a service running in
background is the best way to do it.

Anyway, AutobahnPython is a great server, and AutobahnAndroid is a great
client library, and I would use it for future projects if the
circumstances allows me.

Cheers,
Alejandro

On Sunday, July 8, 2012 10:29:42 AM UTC-4:30, Tobias Oberstein wrote:

    Hi Alejandro,

    great that you are reusing AutobahnAndroid for your project! We
    should probably make AutobahnAndroid more visible as the most mature
    WebSocket implementation - independent of it's WAMP functionality.
    Curious: did you consider any other Android WebSocket
    implementation? I only know weberknecht, and that seems to be
    unmaintained and only implements Hixie-76.

    That said I'm not sure I can follow the project goals fully ..
    Socket.IO provides several fallback mechanism for "plain
    bidirectional messaging". I does not provide RPC or PubSub messaging
    patterns. When Socket.IO can use WebSocket as a transport, it's
    subprotocol does not add anything significant to WebSocket: it's
    just plain bidirectional messaging.

    Honestly, when WebSocket is available, I can't see the point of
    using Socket.IO ..

    Cheers,
    Tobias

    Am Freitag, 29. Juni 2012 04:43:57 UTC+2 schrieb Alejandro Hernandez:

        Hi there,
        Fellas I'm writing to first say thanks for this amazing project.
        Second, I would like to contribute with the community, I
        implemented a client library for the popular subprotocol
        Socket.IO (which some prefer to work with), on top of the
        AutobahnAndroid library.
        https://github.com/magnux/IOBahn
        This is a very early work, with only some hours of work, but
        thanks to its solid base, is a very promising library.
        I like a lot the WAMP, but you know, now we have another flavor
        of WS.

        Thats all folks.
        Regards,

        Alejandro

0 Likes