On Dec 18, 2007 2:07 PM, Brian Smith <[EMAIL PROTECTED]> wrote:
>
> Joe Gregorio wrote:
> > > I agree that there are ways to avoid the confusion. But,
> > > the latency from having to sync with the extra feed is
> > > unacceptable,
> >
> > To whom? And who is bearing the burden of your trade-off?
>
> If the client is on a high-latency connection, then the last thing you
> want to do is double the number of requests and thus double the latency.
> For example, if you have 5 second latency, you don't want to make the
> user wait five extra seconds to verify that he hasn't deleted any
> entries today.
>
> > Most aggregators will ignore the 'deleted' status of an entry
> > and all those deleted entries will just be wasted bandwidth.
>
> That is true if the number of deleted entries is large. But, that will
> be rare for most applications I am interested in. Anyway, Atom isn't
> really a bandwidth-friendly format to start with.
>
> > > especially when
> > > multiplied by dozens or hundreds of feeds.
> >
> > There's no reason you couldn't collapse multiple trash feeds
> > into a single feed, all the atom:ids are universally unique.
>
> I am talking about a client subscribed to feeds delivered from unrelated
> sites.
Those are arguments that actually make sense. I was thinking of
tombstones solely in the case of AtomPub collections, but in the
case of syndication the
<x:deleted>
<id>tag:example.org,2007:/the/only/useful/thing/here</id>
</x:deleted>
markup seems like a better fit.
-joe
--
Joe Gregorio http://bitworking.org
