@dpp thanks I'll be curious to see which of the existing Twitter clients move to the new API or whether we are going to see a new sort of Twitter client.
D. 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 >
