Eric Scheid wrote:
> I think the purpose of PaceAggregationDocument is to provide a
> means to subscribe to an intermediary aggregator like pubsub, and
> thus receive entries.
If that is the motivation, then I think you really should find some
other motivation.
Frankly, it is exceptionally unlikely that we at PubSub could take
the risk of relying on "aggregation" documents since it is probable that it
will be quite some time before substantially all aggregators are updated to
support them. It is much more likely that a large proportion of existing and
new aggregators will rapidly upgrade their Atom 0.3 support to support the
Atom 1.0 feed and entry documents -- but not aggregation documents.
My experience with past protocol upgrading events leads me to
believe that a large percentage of developers will tire once they have the
obvious and familiar bits supported and will then release what they claim to
be "compliant" code but with "aggregation" support "delayed until next
release..." At PubSub, we'll end up with customers complaining that the Atom
we're generating is not supported by their aggregators... Folk will accuse
us of having "buggy code". Competitors will attack us for screwing our users
in some Quixotic quest for "Atom Purity" when we should be addressing user
needs by supporting RSS V2.0 and "core Atom"... No thank you. I really don't
want to go there. Find some other reason to push aggregation documents. But,
whatever you do, PLEASE don't drop HeadInEntry. If you do drop HeadInEntry,
we'll just have to keep using the "ps:" namespace to put it back in.
For us to support aggregation documents might be politically correct
-- if this Pace is accepted, however, it would be suicide from a business
point of view. Please don't ask us to do that which we can not do...
bob wyman
