Re: Super-simple feed format (was Re: Withdrawn entries)

["Randy Charles Morin" <randy@xxxxxxxxxx>]

+1.
The most original idea I've heard in a long time. This is beyond simplicity
and they way it must be done.  Some people can look at a problem and see
thru all the bullshit.

Thanks Seairth,

Randy
http://www.kbcafe.com

----- Original Message ----- 
From: "Seairth Jacobs" <seairth@xxxxxxxxxxx>
To: <atom-syntax@xxxxxxx>
Sent: Wednesday, October 29, 2003 10:06 AM
Subject: Super-simple feed format (was Re: Withdrawn entries)


>
> This one may have already gone by, but...
>
> What if the <feed> format were reduced to a list of URIs pointing to
<entry>
> resources.  For example:
>
>
> <feed>
>     <!-- feed-level elements: title, link, etc. -->
>     <entry uri="http://..."/>
>     <entry uri="..."/>
>     ...
> </feed>
>
> Notes:
>
> 1) If a persistent connection is used, the only bandwidth increase is the
> HTTP headers in subsequent GETs of the individual entries.
> 2) Conditional GETs on those URIs could potentially reduce the bandwidth
> usage.  Over the course of multiple GETs of the feed, this would
especially
> be true (since you wouldn't be retrieving the body of each entry every
> single time).
> 3) Removal of an entry can be implicitly handled by a 410 Gone response
when
> attempting a GET.
> 4) The number of places that an <entry> document is available is reduced
to
> one (while the current approach has at least two, depending on the number
of
> feeds provided).
> 5) This is something different than RSS-all-over-again.  RSS (to my
> knowledge) did not originally conceive of stand-alone entries, hence why
the
> entries are embedded in the feed.  Atom, in contrast, very much focuses on
> entries as their own resources.  Yet we still treat the feed like RSS
does.
>
> ---
> Seairth Jacobs (seairth@xxxxxxxxxxx)
> Looking: http://www.seairth.com/blog/65
>
>