incubator-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 18:23:28 GMT
I think we could use the sampled public timeline for the first screen
that people see before they login.

D.

On Tue, Nov 24, 2009 at 5:34 PM, Markus Kohler <markus.kohler@gmail.com> wrote:
> 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
View raw message