Brion Vibber wrote:
I'd definitely recommend that anybody looking into a streaming API
implementation also take a quick look at how our realtime web delivery
plugins currently work.
The StatusNet-side code plugs into our background queue processing;
for each new notice a chunk of markup with the info for the notice is
whipped up, and it's sent over to an external streaming server
(Meteor, Orbited, or Comet) along with a list of subscribable paths
that it should go to.
If there are any active client connections to the streaming server for
one of those paths, the notice info gets delivered on to them, where
the browser-side JavaScript inserts it into the web page.
I'm not familiar enough with the Twitter streaming API details to know
how difficult it'll be to adapt an existing streaming helper like
Meteor to that API or whether something more purpose-built will be
required, but it's likely going to work on similar lines.
You know, that's probably the right way to do this.
I don't think writing a new streaming server makes sense here.
-Evan
--
Evan Prodromou
CEO, StatusNet, Inc.
e...@status.net - http://evan.status.net/ - +1-438-380-4801
_______________________________________________
StatusNet-dev mailing list
StatusNet-dev@lists.status.net
http://lists.status.net/mailman/listinfo/statusnet-dev
