I realize that there is huge deployed infrastructure where you want
to introduce this extension. And maybe it is a good idea to tip-toe
around and show tombstones only to people who ask for it, etc. From
the technical point of view I think this would do atom a disservice.
The sooner atom feed readers learn to handle extensions properly, the
better for the whole protocol suite.
As Mark noted, the trick with Accept headers only works for few
possible extensions. A good, modern client would some day have to
supply either a long list of extensions it understands or start some
sort of negotation/discovery thing with every server (once a day or
once a week?). "Hey, I know about tombstones and graveyard and
afterlife extensions. Which is the feed url I should really use?"
The alternative I see is to push extensions to client so that they
learn how to deal with the unkown ones. The earlier the better,
future extensions then have it easy. Use a real XML parser, look at
element names and namespaces.
James second example - <x:deleted> intermixed with <entry> - sounds
superior to the first style which basically reads to me "here is the
list of entries, except this one is not, if you know what i mean".
Cheers, Stefan
Am 07.12.2007 um 00:18 schrieb James M Snell:
Using the x:deleted tombstone element, on the other hand, the spam
entry
only shows up once, at a maximum. Readers that do not understand the
tombstone element would act no differently than they currently do and
users should not see any change in current feed reader behavior.
Example: we have a feed with two entries. There are two feed reader
clients, neither of which know about tombstones. Client A requests
the
feed and sees both entries.
<feed>
...
<entry>
<id>tag:example.org,2007:1</id>
...
</entry>
<entry>
<id>tag:example.org,2007:2</id>
...
</entry>
</feed>
Entry 1 is then deleted. Using the tombstone-inside-entry
approach, the
feed becomes
<feed>
...
<entry>
<id>tag:example.org,2007:1</id>
<x:deleted />
...
</entry>
<entry>
<id>tag:example.org,2007:2</id>
...
</entry>
</feed>
Client A gets the feed and still sees two entries, one of which is
marked as being updated.
Client B comes along and requests the feed and see two entries,
both of
which are new to it but one of which doesn't actually exist. Why
should
Client B have to see that entry at all? If the entry was deleted, it
shouldn't be in the feed.
Now use the separate tombstone element,
<feed>
...
<x:deleted>
<id>tag:example.org,2007:1</id>
</x:deleted>
<entry>
<id>tag:example.org,2007:2</id>
...
</entry>
</feed>
Client A continues to operate as it always has when an entry that was
once in the feed suddenly isn't and Client B never has to see the
deleted entry at all. That makes a whole lot more sense to me.
Now, Steven indicates that their implementation will not include the
tombstone by default. Clients that want tombstones would have to
ask for
them explicitly. While that would solve the problem, using the
tombstone element would avoid the need to have that kind of
negotiation
mechanism at all.
- James
Mark Nottingham wrote:
Argh, yeah, good point. This depends on the details of how the
perceive
change etc., of course, but I imagine most would show them twice.
OTOH, this may be good incentive for aggregators to start respecting
tombstones :)
Cheers,
On 06/12/2007, at 11:17 AM, Brian Smith wrote:
Mark Nottingham wrote:
Hmm. Seems like SSE tombstones are good enough for the use
case I illustrated; it's acceptable that clients who don't
understand them ignore them (they'll just see more spam), and
the rest of the entry isn't needed (it's spam, after all).
They will see 2X as much spam: once, when they mark the original
spam as
read, and then they will see the tombstone show up as an updated
entry.
So, effectively, spam is up to twice as bad with the SSE
tombstones as
it is without them.
- Brian
--
Mark Nottingham http://www.mnot.net/
--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782
