On Sun, 6 Jan 2008, Brian Smith wrote:
[snip]
Could you please give an example of such harm. The rationale for James's
design is that it is the least harmful of all the alternatives,
especially the FeedSync design.
Because the "feed abstraction" is that much more complicated. Why is a
bit of metadata as a child of an "entry" element a non-starter?
"deleted","moved", etc. are just attributes of an entry (and
there IS a category element available...). Obviously I don't believe that
a tomstone is anything but another kind (or state) of (an) entry.
The feed abstraction for Atom and RSS is one of a
feed+metadata and a stream of entries+metadata - this has
been the case for the last 10 years, and it isn't going to
change now. The model is not, as would be required if were
to mix entry and feed metadata, a feed+metadata and a stream of
entries+metadata + associations with every feed document that
that entry
entries+has
ever been part of just in case there is some sort of
misplaced entry metadata hidden at feed level, so that
clients looking at an entry can manually reimplement the
sliding window mechanism for tombstones or whatever. Urgh.
Implementations are free to ignore the tombstones and have the exact
same behavior that they have now. That is the primary benefit of this
design over the FeedSync one.
Yes, and then what sort of extension will be proposed for the folks who
want a "deleted" feature, but need/want to keep the deleted entry AS an
entry.
--peter
- Brian
