alternative

[lux]

I started out with orbited when looking for a comet soluition...it was
great for its time, but this project is dead.

I recommend Jwebsocket (www.jwebsocket.org) or node.js for streaming
data to the browser with real websocket support.

good luck!

[Erik Anderson]

If you hunt around for a COMET solution, you may notice that most
sites look pretty abandoned. CometDaily's maturity guide listing
current technology is over two years old (their last blog post is from
july), and most of the webpages I search for seem to be blowing
tumbleweeds. Which really doesn't make sense to me at all, is
everyone calling this tech something different, or has so completely
abandoned it for WebSockets that no one is even using the term any
longer?

My hope for Orbited is/has been for it to turn into something like
Sarissa, which hasn't been updated in years but hasn't really needed
much of one. It just sits there as a thin wrapper filling in whatever
the browser doesn't supply as to give a stable AJAX interface. I
haven't seen jQuery or Prototype provide anywhere near the flexibility
that Sarissa does, and other than a few hiccups over the years it's
been pretty rock-steady.

The current COMET chain I've been building up involves 6 pieces of
code (clients/servers/plugins) written by 5 different organizations
(in 5 different programming languages), more than half have required
significant development time to get up and running. I still haven't
gotten all the pieces working and the fact that there are so many
pieces that require individual babysitting does concern me.

The offering you have here does look like it might be interesting,
replacing the pure-js client with a flash-based one. Not sure I quite
like flash being in the mix (a few of our users are known to block
flash) and I'm *really* hoping that using it doesn't require editing
crossdomain.xml.

[Phil Rhodes]

I suspect that Orbited may have been half dead on the day I found it a
couple of years ago!

Eventually we ended up (slowly, painfully) rolling our own. It was hell
and never worked spectacularly well.

Frankly I found that most of the prepacked solutions were either
overcomplex, relied on the obscure programming language of the day, some
other onerous environment, etc. This is the case with Orbited. There was
(is?) no C# backend for it and we'd have had to commit to installing the
required interpreter on all our servers, which are tiny embedded devices
where that would be a problem, then we'd have had to implement our own
back end for it in .net.

All we wanted was to send data back and forth and get events on either end
when it happened, we were perfectly happy to write the rest of it
ourselves. But it seemed incredibly difficult to build this sort of
solution - well, not incredibly difficult, but requiring a hell of a lot
of hoop jumping.

Is there still no easy solution to this?

Best,

Phil

[Niklas B]

As everything, it depends on your requirements. I love Orbited for the
fact that I can connect it to a raw TCp service (i.e IRC).

However, if you want to have a possibly simpler approach you could
check out http://socket.io/

Regarding wether Orbited is dead or not, well, that's a different
discussion. The old orbited (i.e Orbited 0.7/0.8 don't have much
development done). Orbited2 how ever is starting to pick up pace.

[Phil Rhodes]

> However, if you want to have a possibly simpler approach you could
> check out http://socket.io/

Interesting, thanks - that's useful information :)

P

[Willi Richert]

Hi Niklas,

For my real-time Q&A project, TwoToReal,  I looked into socket.io as well when I realized that Orbited had problems "disconnecting" browser exits properly.

After some experimentation I chose hookbox, because I realized that switching to socket.io would require to rewrite many of the convenience features that are already baked in into hookbox. E.g., you get great Django integration with https://github.com/duaneg/django-hookbox

So, I would be interested in what features you had to rewrite when switching to socket.io.

After all, now that also hookbox seems to be stalled, socket.io gets interesting again...

Thanks,
wr

2011/12/1 Niklas B <biv...@gmail.com>

--
You received this message because you are subscribed to the
Orbited discussion group.
To post, send email to
   <orbite...@googlegroups.com>
To unsubscribe, send email to
   <orbited-user...@googlegroups.com>
For more options, visit
   <http://groups.google.com/group/orbited-users>

[Antoine Tremblay]

While looking at alternatives for this kind of work the best approach I found was http://mongrel2.org/ 

It has tons of language bindings (17 of them). It can scale quite well at the application level. 

It's based on zeromq wich gives it the async behavior you need for this kind of work and more!

In the end I wrote my own solution with cpp-netlib but mongrel2 is a good option to consider and should be much more performant then socket.io or any of the js single threaded stuff... 

Mongel2 is still single threaded though but your application won't have to be, so you can have it do only the IO and thread your application to fit your needs, a proxy like varnish or nginx can help to send the io to multiple instances of Mongrel if you need to but you can still use the same application behind multiple instances of mongrel if you like (so you can keep states or anything)...

Only thing is that you lose the comet protocol so really what you do is long pulling ajax requests directly to the server with your own protocol over http and you use a sessionid to keep the client state, wich is fine with a lot of applications... 

Regards,

Antoine