I disagree with this. Defining the 'publish'/ping mechanism is important to the specification. Just because there can be alternate methods for obtaining this behavior, such as a self-contained publisher/hub, doesn't mean that its purpose is not useful. The publisher notifying the hub that there are updates is a very significant core feature, and leaving that undefined would seem to be a critical mistake, to me.
Section 7.1 is labeled MUST, however if the hub does not provide public services it's rather moot, and that exception is already covered by "If the notification is not acceptable for some reason, the hub MUST return an appropriate HTTP error response code (4xx and 5xx)." "For some reason" is obviously undefined, and can be anything, including the fact that the hub just doesn't support that kind of request. Certainly, if implemented, aspects of those sections are required. i.e. you can't support 'publish' and not support hub.url. On Nov 20, 7:59 am, Julien Genestoux <[email protected]> wrote: > All, > > I believe that the Publisher -> Hub part of the protocol should be left out > of the "core" spec. > The motivation behind it is that many hubs out there (Wordpress, > Superfeedr's... etc) have different ways of handling this without affacting > much of how the general "idea" of the protocol works. > I believe the Section 7.1 should be set as optional, as well as section 7.2. > Something like this would work well, according to me : > Once a publisher designates a hub he wants to use, he then SHOULD use any > of the supported method by this hub to notify new content. 7.1 and 7.2 > should certainly be put as an annex/example of how this can be done. > > What do you think? > > Julien
