True... the problem with magic signatures, is that they require a significant amount of work on the publisher side. even though some may agree to do this, I fear that most will just find this too complex to implement (or at least sufficiently more complex than just using an API key and an https endpoint :p).
Julien On Tue, Nov 22, 2011 at 11:59 PM, Bob Wyman <[email protected]> wrote: > > > On Tue, Nov 22, 2011 at 5:49 PM, Julien <[email protected]>wrote: > >> 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. > > If the payload of a fat-ping were a Salmon Magic Signature, then you > wouldn't need any service or hub specific mechanism such as private API > keys to provide the same level of trust that you get today from reading a > source feed directly. > > >> 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/> >> > >
