On 03/28/2010 01:01 PM, Evan Prodromou wrote:
Josh Roesslein wrote:
A backup idea would be to directly develop the server in C++. This
would require developing a
bridge between StatusNet and the server. New statuses would need to
be passed via a protocol
to the streaming servers.
I think you'd want to do this anyways. We'd probably want to design
this so that new notices go into a queue (we have an extensive queue
system already!), and that offline queue handler processes shuttle the
notices between the queues and the streaming server.
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.
-- brion
_______________________________________________
StatusNet-dev mailing list
[email protected]
http://lists.status.net/mailman/listinfo/statusnet-dev
