esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <>
Subject Re: FYI - Twitter Streaming API
Date Tue, 24 Nov 2009 16:09:07 GMT
On Tue, Nov 24, 2009 at 7:40 AM, Richard Hirsch <>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 <> 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
> >
> >
> > 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
Beginning Scala
Follow me:
Surf the harmonics

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message