Comet usage in Seaside

Dear Seasiders,

How are you using Comet in your web apps? Can you provide some
information about real-life apps in production? What are you
experiences, what are the best practices, any problems?

I'd namely like to know how much the realtime web techniquies are using
in our web frameworks, for a comparison and for my ESUG talk.

Best regards
Janko


--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I use Lukas's Comet code in my Console servers for pushing real-time
market updates to bookmakers.When it works, it works well, but it can
be fragile. I've re-written a lot of my code to use ajax with timers
to get the data, as the pull, can and does fail. Its mostly a browser
issue, I think, and I'm lucky enough to be able to dictate what
browser and version, and even web server that is being used. However,
for future projects, I would use a different method.

I've developed other push servers in Clojure and using ZeroMQ as the
transport layer, and that is a robust and scalable solution. Its also
fast, and is a joy to use (if you'ver ever developed network programs,
and come to ZeroMQ, you'll understand exactly what I mean.

Just thinking out-loud and without getting into details, I think what
we need for Smalltalk is something like this :-

- Stand-alone server loaded into the image. The server acts as a
broker between applications, regardless of the framework they are
using. Each model object in the application, that has data to be
pushed, would inherit from an abstract class that would provide a
#send and #register method, and an id class variable.

- Applications needing push would implement the id using a UUID and
call #register in their #initialize method. When they have data to
send, they call send, and all data is encoded as NetStrings.

- If the server has registered clients (registered using the same
UUID, or even a RestFul URI) for this data, it would be pushed out,
otherwise the message would be dropped (Depending on the requirements,
the messages could also be queued upto a High Water Mark, and batch
sent the first time a client connects).

- Now the server could implement its own protocol handlers for
long-poll, WebSockets, FlashSockets etc., and track all incoming
registrations. All data pushed from applications would be multiplexed
to the registered clients. Note, that the clients would normally be
browsers, but they could also be mobile apps etc. One way to achieve
this would be to develop ZeroMQ binding for the VM, with a nice
Smalltalk interface for the server to use. Then the server's handlers
become Mongrel2 handlers, and Mongrel2 takes care of all the http
stuff, and the client registrations.

Just a thought.

2011/7/4 Janko Mivšek <[hidden email]>:


--
~JT
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside