Friday, January 6th, 2006

Google RSS Reader: Ajax and Continuations

Category: Editorial, Google

Niall Kennedy has disected the Google RSS Reader, which gives us a look into how Google does its thing.

Nick Lothian then took this further, looking into the Ajax lens and finding out about how Google uses Ajax and continuations.

So I was mucking around with Niall’s excellent reverse-engineering of the Google Reader, and I figured out that Google have some pretty must have some pretty funky (in a good way) framework to work with client/server interactions from Javascript.

The UI has a feature called the “Lens”, which allows one to scroll through blog posts. Posts are requested 20 at a time (and returned in an the Atom XML format). Once you scroll more than 20, another HTTP request is required. The usual way to do that would be to pass some kind of “start” parameter, but instead the Atom file contains a element which contains a unique ID (think of it as a session ID).

This id can be passed to the Google feed URL endpoint, and it will return the next 20 elements starting from where you left off.


  1. request: GET /reader/atom/feed/
  2. response: <feed>…<gr:continuation>COT3ruq0jYIC</gr:continuation>…</feed>
  3. request: GET /reader/atom/feed/
  4. response: Contains the next 20 elements

I’d really love to see the framework that is doing this stuff.

Google released their XSL stuff, but would they give up tools that potentiall give them a headstart over competition?

Posted by Dion Almaer at 11:13 am

3.6 rating from 22 votes


Comments feed TrackBack URI

[…] […]

Pingback by Project :: penkiblog » Blog Archive » 本日書籤 — January 7, 2006

That’s Nick _Lothian_ – thanks for the link, though…

Comment by Nick Lothian — January 7, 2006

Why is this good?

Now you have to maintain state on the server. A start parameter would allow you to do this in the client and all you have to do is cache your index on the server and you’re done.

While google certainly has the resources to maintain the state on the server I’m sure wasting them isn’t a good idea.


Comment by Kevin Burton — January 8, 2006

Yeah, I thought the same as Kevin – I’m not convinced of the wisdom of this. The only thing I could think of was that Google maintains that state on the server for some other reason.

Comment by Nick Lothian — January 8, 2006

Who says the ID is a session ID and not the ID for the currently last viewed article? Using an index / start-parameter in the current list of articles at the time of viewing is not the best way when the list you are using can change over time like a blog does. Keeping the ID for the last viewed article doesn’t require state on the server and keeps your list from ‘jumping’ when the article list on the blog happens to change between the view of the first 20 items and the next 20.

Comment by Wilem Joosten — January 9, 2006

It’s not the ID of the last article – if you re-request the same URL you get different IDs

Comment by Nick Lothian — January 9, 2006

Leave a comment

You must be logged in to post a comment.