Huh. Well, I agree with you : discovery MUST stay standard and used by all publishers in the same manner. What I think is not relevant to the spec is HOW the publisher pings the hub. Now, I'm ok to leave it in the spec, but then, we have to accept and understand that MOST implementations out there do not have a 100% PubSubHubbub compliant mechanism. That would be a pity because as a matter of facts, it doesn't affect anything anywhere.
As for preventing the lock in, it's extremely easy for a hub to implement MORE mechanism to make sure anyone who wants to migrate to them can do so easily... again, since there is already a coupling by necessity, I think it's kind of useless to define a protocol whose goal is to decouple things! As for the fat ping mechanism you're describing, we have implemented exactly this at superfeedr. The main issue with this though is that the hubs needs to have a way to trust the fat ping coming from the publishers. In our case, that involves using a private API key, but again, that is not standard by any mean, and I don't think it should be, as others may want to use other mechanisms. Others? On Nov 22, 11:34 pm, "Jay R. [dlvr.it]" <[email protected]> wrote: > On 11/22/2011 2:13 PM, Julien Genestoux wrote: > > > > > > > > > > > Jay, > > > I think the spec should say something like : "The publisher MUST inform the > > hub about new content." without which, obviously the protocol won't work. > > However the "how" should be left outside the protocol, or may be something > > like "the hub MAY implement method X to get notifications". > > I think one of the "design" principles of the protocol was that subscribers > > should not care which hub a feed is using as their subscription should work > > with *any* hub. On the other end, since the publisher designates a *specific > > hub*, the hub and the publisher can agree on the method they want to use > > without affecting anyone else. > > In other words : there should be no coupling between subscribers and hubs, > > no coupling between subscribers and publishers, but since there is coupling > > (thru the discovery) between the hub and the publisher no matter what, we > > should probably not spec it. Does it make sense? > > Honestly, no - it doesn't make sense to me. The whole point of the > specification is to define expected behaviors universally. If a hub wants to > enable alternate discovery methods outside of the specification, there's > nothing preventing that, but I believe that having this defined is of > significant benefit to publishers. No matter what hub they use, they always > know that whatever software they implemented for notification will continue to > work. The publish method is ubiquitous at that point - there's no guesswork > for anyone involved. If made optional then every hub may institute different > policies which are /not/ universal. > > By leaving update discovery methods up to each implementation, you're enabling > user lock-in because they won't want to go through the extra work required by > whatever their new hub might implement. > > I always found it a failing that there was no ability for the publisher to > send a content blob along with their notification. In essence this turns the > publisher into a pseudo-hub, however they're only distributing to the central > hub, not directly to clients (and without adding hub discovery). This becomes > important in situations where publishing content may be behind a time-delay on > file updates. (e.g. a CDN, etc.) In the end, this just turns toward the > discussion of hub chaining (which has never been defined), not general purpose > publishing. > > -- > Jay Rossiter | Jack of All Trades > [email protected] <mailto:[email protected]> | Phone: 503.896.6187 | Fax: > 503.235.2216 > Website: dlvr.it <http://dlvr.it/> | RSS: blog.dlvr.it <http://blog.dlvr.it/> > | Support: support.dlvr.it <http://support.dlvr.it/>
