[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tombstones Update
The Tombstone draft is coming along nicely, however, I can't help wondering... Since it appears that a deleted-entry is so much like a normal entry, why isn't it just an extended atom:entry with some additional element or attribute flagging it as deleted?
There are a number of "deletion" use cases, some of which already have support in the base Atom Format specification. For instance, since Atom defines "replacement," (i.e. publish an entry with the same atom:id as one previously published but with a later atom:updated date), there is already a crude method for asking that content be removed from aggregators. However, this tends to encouraging people to publish entries that have titles of "Deleted," content of "Deleted." Etc. Not particularly elegant -- but it works, sort of.
I'm afraid that if deleted-entry is introduced into the system, what we'll see is that during some arbitrarily long transition period while we wait for people to modify their software to support deleted-entry, people who really want to purge the network of some late night blog post will tend to publish both a "Deleted" replacement entry as well as a deleted-entry... They would do this since it is potentially going to be a long time (perhaps infinite) before deleted-entry is widely implemented and just publishing a normal entry has much the same effect (but not completely) of publishing a deleted-entry.
If, on the other hand, the definition of entry was extended to permit a "deleted" flag or attribute, then we'd find that applications would have implicit support for entry deletion without needing to write any more code. Certainly, applications that understood what a deletion actually meant and that understood the extra fields like when, by and comment, would be able to do interesting things based on that understanding.
I'm also concerned that the utility of the deleted-entry mechanism is limited to only those systems that rely on "topic-based" filtering -- i.e. following a specific feed and consuming all of its content. We would need some entirely different mechanism to support content-based filtering -- i.e. extracting entries based on their content (presence of words, phrases, etc.). Deleted-entry can't help a content-based system since unless such systems maintain cumbersome logs of all atom:ids that are published and who they were published to. The problem is that since a deleted-entry contains virtually none of the data contained in the entry deleted, any topic-based filtering can't figure out who might have previously received a copy of the now-deleted entry.
Of course, the easiest way to delete things in a content-based system would be to republish the original entry (with all its content) and mark the entry as "deleted." This will work in, but not all applications, since in some applications, one does not wish to republish the data that is being deleted. However, in at least some applications, where one can trust that consumers are paying attention to the deleted flag, it is acceptable to republish the now out-of-date data.
If a deleted-entry is so much like an entry, why can't it just be one? (with some extra metadata).
2010/5/21 James Snell <jasnell@xxxxxxxxx>
Quite a few important updates.
>> On Wed, May 19, 2010 at 1...
> On Thu, May 20, 2010 at 8:54 AM, Ed Summers <ehs@xxxxxxxxx
Ok, looks like we've got quite a bit good support for standalone
docs.. I'll add that in.
> representations), I see potential for usi...
> Apart from the use cases already mentioned (XMPP, 403
No prob. Thanks for the great feedback and input.
> * What would the mime-type for deleted-entry documen...
> Two points come to mind if this is done:
Putting these under the application/atom+xml media type would likely
cause badness. I'm thinking something like
> PUT:ing deleted-entry do...
> * For good measure, making sure that this doesn't lead to a pattern of