Refreshing 100 feeds
It is no easy task, specially if you want to provide the best user experience without interrupting the flow of the application.
Here are the options we have:
#1. One server call to refresh them all. One response to notify them.
#2. Multiple server calls, one per feed. 100 asynchronous responses.
#3. One server call with 100 multipart responses.
Pros and cons:
#1. Placing one call to the server and marking all feeds as being refreshed, uses only one http channel, allowing full navigation of the application. The server loops and updates the feeds leaving the client unaware. No visual reference of the progress of the feeds. All feeds are reset when the final response arrives.
#2. Client loops the feeds, placing one asynchronous call per feed, it will be visually marked as soon as we get the response back. Intensive use of resources since it has to open 100 channels and deal with 100 asynchronous responses. The best visual response, but sends any additional user http request to the end of the queue, almost locking the application.
#3. One server call, multipart responses using the same channel. The server loop the feeds and return the response for that feed which is updated on the client. Sequential/asynchronous visual update. Full navigation and free resources to read while refreshing.
A month ago I started with #1 since I was not indicating updated feeds. Then I went with #2 and the first thing I noticed is that I couldnt read my blogs while refreshing the feeds.
Today I decided to try #3, XMLHttpRequest with multiparts and it is working nice. It allows navigation while providing visual references of the feeds being refreshed.
Let's put it to the test for some days.
posted by XULPower @ 10:09 PM
5 comments
5 Comments:
QUestion about this;
Does the server fetch and parse the feeds on every log on, or is it don constantly in the background a certain amount or times per day?
Meaning, does the user invoke fetching and parsing of feeds or is that totally handled by the server?
Thanks.
The client always get the copy in the server's cache.
The server updates the cache only if a user requests a feed and the conditional GET (if-modified-since) response is other than a 304 code (not modified).
To add to that, the server does not fetch feeds in the background. Only per users request.
So, if users don't refresh slashdot, the copy in the server will be outdated until somebody asks for the latest.
Thanks for the feedback.
Another thought, would it be possible to do an automatic refresh on load?
When I come back to check my feeds, I have to manually click on 'refresh all feeds' to see if anything new has arrived.
Thanks.
That's a debate we're having, since we don't save posts, if we refresh the roll you would lose all the old feeds you were waiting to read when you got home.
But good news in the horizon:
- We can make it an user preference
- We will save posts in the near future
We are studying the storage upgrade requirements to keep up to a month of old posts for all of our users.
Then auto-refresh on load will be standard.
I'd say the user preference is most likely to happen in the next days.
Post a Comment
<< Home