It sounds like you need a workflow. Create a feed of entries with some flag extension. Flag all your unprocessed entries. Remove the flag as you process them so that they will disappear from the feed. Ordering by updated still poses no problem that I can see.
http://www.intertwingly.net/wiki/pie/PaceWorkflows I acknowledge that back-splicing old entries into a feed after the fact will cause them to be missed at sync. Repairing broken feeds and the like would require the client to either a walk back through the whole feed (or at least to a specified date) or use a "repaired entries" feed of some kind. I this such a common case that we need to change the ordering of feeds in the core to make it easier? (sincere question) Is there some implication of your example that I missed? - Luke On 11/9/05, Henry Story <[EMAIL PROTECTED]> wrote: > Hi Luke, > > I wanted to write out yesterday that I think the opposition > may have a point in this argument. But I ran into other things to > do. > > The discussion led me to think of the following. Imagine we wish to > publish a series of changes to atom entries. We don't just want to > publish the document as it is now, but we wish to publish the whole > history > of the document. > > So we have an the following atom entry's [1] > > [ a :Feed, :Version; > :entry [ a :Entry, :Version; > :title [ :value "Atom-Powered Robots Run Amok"; > :type "text/plain" ]; > :link [ :href <http://example.org/2003/12/13/atom03>; > :rel iana:alternate ]; > :id <tag:example.org,2003:3.2397>; > :updated "2003-12-13T18:30:02Z"^^xsd:dateTime; > :summary [ :value "some text"; > :type "text/plain" ] > ]; > :entry [ a :Entry, :Version; > :title [ :value "Atom-Powered Robots Run Amok in France"; > :type "text/plain" ]; > :link [ :href <http://example.org/2003/12/13/atom03>; > :rel iana:alternate ]; > :id <tag:example.org,2003:3.2397>; > :updated "2003-12-14T18:30:02Z"^^xsd:dateTime; > :summary [ :value "some text"; > :type "text/plain" ] > ]; > ]. > > So we have two entries versions above with the same id > <tag:example.org,2003:3.2397>. > > We may now wish to copy the history of our changes from one server to > another. What > with all these government probes and laws for checking the integrity > of information, > you may be wise to keep a copy of all the changes to a blog entry > when you save them > over to your StorageTek [2] warehouse. You don't want the government > probe to put > your whole business on hold because the agent suspects that you > deleted all the old > versions of some entry that he thinks (probably falsely) were trying > to subvert > the government. > > So now. We have 2 versions of an entry. Rummaging around an old > server log file you > discover a third version of your entry. > > [ a :Entry, :Version; > :title [ :value "Atom-Powered Robots Run I am ok"; > :type "text/plain" ]; > :link [ :href <http://example.org/2003/12/13/atom03>; > :rel iana:alternate ]; > :id <tag:example.org,2003:3.2397>; > :updated "2003-12-11T18:30:02Z"^^xsd:dateTime; > :summary [ :value "some text"; > :type "text/plain" ] > ]. > > How is this entry ordered in the feed? > Can we add a history of changes to the server with this protocol? > > Henry > > [1] still using the atom-owl ontology at http://bblfish.net/work/atom- > owl/2005-10-23/ > it should be obvious just by reading the above how it relates to > the atom-syntax > [2] http://www.storagetek.com/ > > On 7 Nov 2005, at 16:27, Luke Arno wrote: > > On 11/7/05, Eric Scheid <[EMAIL PROTECTED]> wrote: > >> > >> On 8/11/05 1:46 AM, "Luke Arno" <[EMAIL PROTECTED]> wrote: > >> > >>> None of you arguments have convinced me that most > >>> cases need insignificant updates before edit time. > >> > >> this is perhaps because you are using a different definition of > >> significant > >> update than what is in the format spec. > >> > > > > I ask you again not to put words in my mouth. > > > > We differ on the our view of conflict resolution. > > > > Lets just drop this rathole. > > > > We need to decide what we are doing about > > conflicts before this argument (which has > > become inane) has any meaning. > > > > - Luke > >
