esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: FYI - Twitter Streaming API
Date Tue, 24 Nov 2009 16:14:44 GMT
@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
<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
View raw message