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/> >
