RE: more on the simplified feed format

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

Hmmm! I missed something obvious here. Shouldn't Atom implement Dare's
scheme on reducing bandwidth? Or is this already a done deal that I
missed?

Randy
http://www.kbcafe.com

-----Original Message-----
From: owner-atom-syntax@xxxxxxxxxxxx
[mailto:owner-atom-syntax@xxxxxxxxxxxx] On Behalf Of Randy Charles Morin
Sent: Friday, November 07, 2003 12:24 AM
To: 'Seairth Jacobs'; atom-syntax@xxxxxxx
Subject: RE: more on the simplified feed format



I think your original suggestion was better. I don't think bandwidth is
such an issue that we require such complexity. Also, it's not super
simple, just simple. I like the super simple thing together with Ken's
attribute in the HTML suggestion. This is the way RSS should have been.
Atom did a great deed in revealing this. MHO,

Randy
http://www.kbcafe.com

-----Original Message-----
From: owner-atom-syntax@xxxxxxxxxxxx
[mailto:owner-atom-syntax@xxxxxxxxxxxx] On Behalf Of Seairth Jacobs
Sent: Thursday, November 06, 2003 11:11 PM
To: atom-syntax@xxxxxxx
Subject: more on the simplified feed format



Having recently read Dare's blog entry 
(http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=771d294a-a459-402
f-9cdf-a78eee845175), 
I would like to push the simplified feed format again.  However, I would

like to suggest a slightly modified version.  For each <entry>, I 
suggest the following:

<entry etag="" guid=""></entry>

"etag" would contain the http-equivalent etag value for the entry being 
pointed to.  This way, if the entry changes, it can be easily detected.

(side note: for versioning tools like wikis, could you use the 
current-version URL as an etag value?)

"guid" would contain the same value as in the <entry> document's <id> 
element.  I only named it "guid" here to avoid confusion with the xml:id

attribute.  This way, if the URL of the entry changes, we would avoid 
thinking a new <entry> document was created.  As long as the etag value 
stayed the same, it would not be necessary to fetch the <entry> document

again.

And, of course, the content would still be the URL of the <entry> 
document.  Beyond these values, I do not think any additional 
information about the <entry> document should be conveyed in the feed.  
"etag" is safe because it's representive of the <entry> document itself,

not a piece of information within it.  "guid" should be safe because 
it's never supposed to change.  But every other piece of information in 
an <entry> document is editable (either by the user or the server).  As 
a result, they should only be in the <entry> document and not in the 
feed as well.

Now, back to Dare's post.  Using this approach, it is no longer much of 
an issue to retrieve an entire feed every time. A feed containing 
pointers to 10-15 items would still be only a couple KB in size and 
would also be easier to compare.  And, of course, you could (should) 
still optimize the feed more by supporting the 304 response for the feed

itself.

Seairth