incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Kohler <markus.koh...@gmail.com>
Subject Re: FYI - Twitter Streaming API
Date Tue, 24 Nov 2009 16:34:14 GMT
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 <feeder.of.the.bears@gmail.com
> wrote:

> On Tue, Nov 24, 2009 at 7:40 AM, Richard Hirsch <hirsch.dick@gmail.com
> >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 <esjewett@gmail.com>
> 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
>

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