Hi all, Maybe I'm missing something, but isn't this just Comet ( http://en.wikipedia.org/wiki/Comet_(programming)) ?
I find the "sampling" approach of the public timeline interesting. We have been talking about removing the public timeline. An alternative would be to offer only a sampled public timeline. Regards, Markus "The best way to predict the future is to invent it" -- Alan Kay On Tue, Nov 24, 2009 at 5:09 PM, David Pollak <[email protected] > wrote: > On Tue, Nov 24, 2009 at 7:40 AM, Richard Hirsch <[email protected] > >wrote: > > > What I think is also interesting is how Twitter documents this new > > API. maybe we can use this as an example. > > > > What are the advantages of our method vs. their method? > > > > The advantage of their mechanism is that it's a smoother experience. What > we've done with chunking/long polling is to simulate a stream of data on > top > of a non-streaming protocol. What Twitter has done is to say "this is a > one-way conversation, we've got an open TCP/IP connection, so let's use > it." > > Implementing what they have would require going below the current set of > abstractions that Lift provides above the Servlets. > > At a practical level, the difference is at one layer... the one dealing > with > the HTTP requests. At the layers above, events flow either way. > > > > Or are there > > basic philosophical differences? > > > > At the basic philosophical level, Twitter's implementation is purer. It > treats a stream of information as a stream of information. > > I like it, but I'm not sure what the benefits would be vs. the development > costs of implementing such a mechanism (unless there's an en mass migration > of microblogging clients to such a mechanism). > > > > > > D. > > > > On Tue, Nov 24, 2009 at 4:33 PM, Ethan Jewett <[email protected]> > wrote: > > > All, > > > > > > I hadn't gotten the chance to look at this before, and it is > > > interesting. Twitter now has another take on a message-streaming API > > > over HTTP, using what looks like a non-HTTP-1.1-compliant form of > > > request pipelining (sending multiple responses over a single open > > > connection). See the documentation at > > > http://apiwiki.twitter.com/Streaming-API-Documentation > > > > > > This is not what we are doing currently. I'd describe our current API > > > design as more of a delta-queue approach, while Twitter's design is > > > more of a true stream-over-HTTP. > > > > > > Food for thought. > > > > > > Ethan > > > > > > > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics >
