Pádraic Brady wrote:
Maybe there's a middle ground through. Where Superfeedr normalises to an
Atom subset, and the Google App hub normalises nothing, there perhaps is
room for configurable normalisation. A service where Subscribers can
opt-in to normalisation and configure the most interesting subset for
their uses. It'd be more complex to the Hub (diverging requirements may
harm efficiency) but maximise value to all users.
I think the important distinction is who the hub is acting as an agent of.
If the hub is acting as an agent of the publisher, then the publisher
will choose a hub which presents the data in a way that is acceptable to
the publisher. A publisher already decides whether to support RSS, Atom
or both; in the base case the dumb hub will treat each of these feeds as
distinct and it'll be up to the consumer to select the one it supports
just as with feeds today.
If the hub is acting as an agent of the consumer, as in the Superfeedr
case, then any normalization it does is functionally equivalent to
having that same normalization done in the consumer code inside the
consumer itself... the consumer is offloading that work to superfeedr.
The case where a hub is acting as an agent of the publisher is the
primary model that the Hubbub spec considers.
The case where the hub is acting as an agent of the consumer is really
just an implementation detail of a consumer and doesn't need to be
catered for by the spec itself. Superfeedr really just uses the Hubbub
wire protocol has a convenience to avoid its customers needing to
implement something proprietary (or needing to implement an XMPP
listener) so really this communication has two known parties with an
pre-existing relationship (the consumer has a user account on
Superfeedr) so the way these two parties communicate is no business of
anyone but those two parties. Superfeedr's normalization is a
proprietary implementation detail.
So on reflection I think the Hubbub spec should go on being about the
case where the hub acts as an agent of the publisher, and thus should
describe a hub that passes things through verbatim. Services like
Superfeedr are free to use the wire protocol from the Hubbub spec as the
basis for their service to consumers but this is not really a concern of
the Hubbub spec except that it should not specify anything which makes
this kind of protocol reuse more difficult.
The Hubbub spec should *not* describe any kind of normalization behavior
since this will presumably be the differentiator between different
Superfeedr-like services and so they should be free to innovate their
normalization mechanisms in response to the needs of their customers,
just as they might also choose to provide protocols other than Hubbub if
that too serves the needs of customers.
