Subject: Re: [habari-dev] Re: Timestamps

From: Geoffrey Sneddon <[email-masked]>
Date: Sat, 16 Feb 2008 21:47:36 +0000

To those on atom-syntax who've got this through being CC'd, Habari  
currently uses one feed for both end users and the APP collection, and  
is currently sorted by atom:updated (which is currently any update,  
but seems to be little opposition to fixing that) — the seeming issue  
is splitting the end user feed and the APP collection up, as several  
are questioning what the need to actually order by app:edited is. What  
really is the need for it to be ordered by app:edited? I can see  
nothing in the archives or on the wiki about the ordering (apart from  
its introduction).

On 16 Feb 2008, at 18:54, Ben Ramsey wrote:

> On 2/16/08 6:54 AM, Geoffrey Sneddon wrote:
>> The other importance that this change makes more obvious is that the
>> Atom Syndication Feed and Atom Publishing Protocol collection need to
>> be in separate documents, as they have different sorting  
>> requirements.
>
> I see no need for them to be separate documents.
>
> Section 4.1.1 of RFC 4287 states "this specification assigns no  
> significance to
> the order of atom:entry elements within the feed." So, I don't see  
> where the
> Atom Syndication Format specifies how entries should be ordered.  
> AtomPub simply
> takes this a step farther by actually assigning significance to the  
> order,
> stating in section 10: "Entries in the returned Atom Feed SHOULD be  
> ordered by
> their 'app:edited' property, with the most recently edited Entries  
> coming first
> in the document order."

I didn't mean ASF actually required any specific order, I meant that  
for end users it makes no sense to order the end user feed by  
app:edited (as nobody cares about a typo from several years ago being  
corrected, for example); we have no valid reason in our circumstances  
to order the APP collection (by app:edited) against the "SHOULD" in  
APP, so in that way they have conflicting needs. This means they need  
to be separate documents.

> To me, this doesn't warrant a distinction between Atom Syndication  
> Feeds and
> Atom Protocol Collections. Section 10 of the protocol also states: "No
> distinction is made between Collection Feeds and other kinds of  
> Feeds." To me,
> this means that they should be treated exactly the same. The  
> Protocol simply
> adds a few more rules to Feed.

Yeah, sure, it's possible to have them as the same, but to follow what  
APP actually says you need it ordered by app:edited, which makes no  
sense in the context of a normal feed that readers subscribe to.

--
Geoffrey Sneddon
<http://gsnedders.com/>

---

From: John Panzer <[email-masked]>
Date: Sat, 16 Feb 2008 14:29:12 -0800

So the rationale for ordering by app:edited is so that edit-oriented 
clients can easily synchronize their local copies of the collection with 
the server side versions.  They need to walk back only as far as their 
last synchronization.  This is a different need than read-only 
syndicators, which usually don't care about missed entries and as you 
point out don't care about a typo fixed in something from two years ago.

So you have two use cases for the same data.  You can use the same feed 
for both, but you'll need to compromise a bit.  Or you can have two 
feeds and tailor each.

Blogger, the software I work on, has the same issue of course.

John

Geoffrey Sneddon wrote:
>>> be in separate documents, as they have different sorting requirements.
>>
>> this means that they should be treated exactly the same. The Protocol 
>> simply

---

From: "Brian Smith" <[email-masked]>
Date: Sat, 16 Feb 2008 19:09:33 -0800

Geoffrey Sneddon wrote:
> To those on atom-syntax who've got this through being CC'd, 
> Habari currently uses one feed for both end users and the APP 
> collection, and is currently sorted by atom:updated (which is 
> currently any update, but seems to be little opposition to 
> fixing that) — the seeming issue is splitting the end user 
> feed and the APP collection up, as several are questioning 
> what the need to actually order by app:edited is. What really 
> is the need for it to be ordered by app:edited? I can see 
> nothing in the archives or on the wiki about the ordering 
> (apart from its introduction).

Usually a blogging server will implement app:draft in a way that the
collection feed will contain draft entries and the public feed won't.
So, you need (at least) two feeds anyway.

There have been many discussions on the atom-protocol list about how to
efficiently synchronize a client's copy of a collection with the
server's copy. Those synchronization mechanisms are based on the premise
that a client can page through the feed until it gets to an entry with
an app:edited timestamp that is earlier than the last time it synced,
and then stop. Unless you sort by app:edited, your server will not
interoperate with any client that works like this. 

When media resources (images, videos) are updated, the media link entry
in the collection feed for that media resource should have its
app:edited timestamp updated. If you insist on sorting by atom:updated
then make sure you update atom:updated in that case.

When I implemented an AtomPub server, I also found there to be some
performance reasons for implementing a separate collection feed. First,
you can combine all the media link entries with the regular entries in
the collection feed, but you would never want to do that for your public
feed. Also, there is really no reason for a collection feed for a blog
to contain anything close to the full content of the entry; if you cut
out all the optional bits of the entry (besides the summary, which is
sometimes useful for the blog editor), you can fit a lot more entries
per KB in the collection feed in your (usually full-content) public
feed, and/or you can make the collection feed pages much smaller. I am
usually able to fit about 4 blog entries per kilobyte (compressed) in my
collection feeds document, whereas the entries in the full-content
public feed are usually ten times that size.

- Brian