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 <[email protected]> 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 <[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 >> >
