Re: non-solutions for blogs.msdn.com: (was RSS consumes too much bandwidth)

[Eric Scheid <eric.scheid@xxxxxxxxxxxxxxx>]

On 10/9/04 1:27 AM, "Eric Scheid" <eric.scheid@xxxxxxxxxxxxxxx> wrote:

> you could possibly do something like this today without requiring changes to
> aggregators ... if the aggregator respects 301 MOVED, then the publisher can
> change the subscribed URL for every request.
> 
> The inspiration comes from Simon Willison [1] ... except with the URL
> changing more often (ie. per user per feed update) ... thus the feed I'm
> subscribed to might be
>   http://example.org/feed.atom?user=000234&last=20040909T1323
> which then changes (via 301 MOVED) to
>   http://example.org/feed.atom?user=000234&last=20040910T0805
> and so on.

> [1] http://simon.incutio.com/archive/2004/09/01/track

thinking on this some more, I figure the publisher doesn't even need to keep
track of individual users to know their last access point (to do the diff
from) ... the diff date could be built into the url...

A long example:

1.  User subscribes to http://example.org/feed.atom
2.  User requests http://example.org/feed.atom
3.  Server responds with
    301 MOVED http://example.org/feed.atom?from=[datetime#1]
    where [datetime#1] is feed last mod date
4.  User's aggregator updates the subscribed URL, and then requests
    http://example.org/feed.atom?from=[datetime#1]
5.  Server responds with full content and all entries

some time later, but no changes at the server end...

6.  User requests http://example.org/feed.atom?from=[datetime#1]
    and if-modified-since
7.  Server sees no changes since [datetime#1] nor if-modified-since
    responds with 304 NOT MODIFIED

some time later, now with changes at server end ...

8.  User requests http://example.org/feed.atom?from=[datetime#1]
    and if-modified-since
9.  Server realises there have been changes since and responds with
    301 MOVED http://example.org/feed.atom?from=[datetime#1]&to=[datetime#2]
    where datetime#2 is the new last-feed-mod date
10. User's aggregator updates the subscribed URL, and then requests
    http://example.org/feed.atom?from=[datetime#1]&to=[datetime#2]
11. Server sees changes since datetime#2 and so responds with
    feed containing only entries between datetime#1 and datetime#2

some time later, but no changes at the server end...

12. User requests with if-modified-since
    http://example.org/feed.atom?from=[datetime#1]&to=[datetime#2]
13. Server sees no changes since datetime#2
    responds with 304 NOT CHANGED

some time later, now with changes at server end ...

12. User requests with if-modified-since
    http://example.org/feed.atom?from=[datetime#1]&to=[datetime#2]
13. Server realises there have been changes since datetime#2 ...
    301 MOVED http://example.org/feed.atom?from=[datetime#2]&to=[datetime#3]
    where datetime#3 is the new last-feed-mod date (and note that datetime#2
    has shifted to the 'from' argument)
10. User's aggregator updates the subscribed URL, and then requests
    http://example.org/feed.atom?from=[datetime#2]&to=[datetime#3]
11. Server sees changes since datetime#2 and so responds with
    feed containing only entries between datetime#2 and datetime#3

and so on.

The really neat thing is that this doesn't break any intermediary caches as
each possible feed variation has it's own unique URL. All this needs to work
are aggregators which respect the 301 MOVED response, which they should be
doing already anyhow.

Now where do I go to collect my medal ;-)

e.