Meteor might be a possible option since it seems flexible enough and does use plain HTTP. Orbited seems more focused on "sockets" for the browser. Cometd uses a special protocol.
Twitter's Streaming API is plain HTTP. We would still need a server in front of Meteor to map Twitter compatible streaming URL's to Meteor's URL scheme. This server would also perform authentication and create new channels for the filtering endpoints (location, keywords, users). For example if user A connects and wants all notices that have the keywords "apple", "pear", "orange" we would have to create channels for each of those. Users that share common keywords would also share the same channel. When a new notice is generated we examine the channel table and determine which channels the notice needs to be dispatched. This action could occur in an offline daemon using a queue to grab new notices from to be dispatched to the meteor channel(s). Josh On Tue, Mar 30, 2010 at 6:45 AM, Evan Prodromou <[email protected]> wrote: > 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. > [email protected] - http://evan.status.net/ - +1-438-380-4801 > > _______________________________________________ > StatusNet-dev mailing list > [email protected] > http://lists.status.net/mailman/listinfo/statusnet-dev >
_______________________________________________ StatusNet-dev mailing list [email protected] http://lists.status.net/mailman/listinfo/statusnet-dev
