Mathieu, Thanks for jumping in the discussion... The main reason that we picked a couple months ago was that to many people PubSubHubbub was "a Google thing", and that's bad when Google have been publicly divesting from RSS/Atom feeds in general. So, by moving away from Google properties, we could show that PubSubHubbub was not linked to Google more than to any other participant in this ecosystem.
Addtionnaly, I have to say that the Github interface is much much much friendlier than the Google Code stuff! Thanks, -- *Got a blog? Make following it simple: https://www.subtome.com/ <https://www.subtome.com/>* Julien Genestoux, http://twitter.com/julien51 +1 (415) 830 6574 +33 (0)9 70 44 76 29 On Sat, May 31, 2014 at 12:09 AM, 'Mathieu Robin' via Pubsubhubbub < [email protected]> wrote: > Hi John, > > So to answer you initial question, yes we (the eng team working on the > Google hub) are still out there. And that's even part of our "real" job :) > We'll keep an eye on new issues from now on, unfortunately email > notifications were disabled and the issues you posted went unnoticed. > > Julien already addressed your comments. Going forward, I'm also not sure > where protocol discussions should take place. Any reason to move these to > Github? > > Thanks, > Mathieu > > -- > Mathieu Robin > Tech Lead Manager, Google Switzerland GmbH > +41 78 696 27 04 > > > On Fri, May 30, 2014 at 6:06 PM, Julien Genestoux < > [email protected]> wrote: > >> John, >> >> Not all activity is conversations :) >> Recently, Medium, for example started supporting PubSubHubbub (through >> Superfeedr!) >> >> Now, though, I'm not sure the Google Group is the best place to report >> protocol issues. You should try Github :) >> https://github.com/pubsubhubbub/PubSubHubbub/issues?direction=desc&sort=created&state=open >> >> Now, for issue " Subscription Validation and Verification of Intent >> should use POST". >> This has been pondered in the past, but technically the hub is not >> sending any data to the subscriber, but rather asking something, which is >> why the GET request seems more appropriate in the REST terminology. In the >> end, the benefit of using GET is also that we have different logic between >> verifications of intent and notifications, which is a nice feature and >> makes it easier to implement subscribers! >> The scenario that you describe, where the subscriber changes the state of >> the subscriber on its end is one possible implementation... others (like >> Superfeedr) actually "persist" the subscription when we issue the >> subscription request. We mark it as "verified" when the verification of >> intent (but that does not change the behavior), and we later mark it as >> "functional" when we get a notification on that callback. This helps us >> quickly identify how "broken" a given notification can be. >> >> Then, for issue "Specific content-type for Subscription Request". >> The Content-Type of the subscription request applies to the supplied body >> of the POST request, not to the content of the hub.topic. So, unless you >> provide a BODY that's in a different format, you *have to* use >> "application/x-www-form-urlencoded". >> That being said, we could very well imagine that the subscription request >> BODY is a JSON document, like {hub: {mode: 'subscribe', topic: '...', >> callback:'...', verify: 'sync'}}. If that was the case, the subscriber >> would need to use "application/json" as the Content-Type. >> What you describe with application/pubsubhubbub+xml is certainly >> possible, but I don't see the need for it (it adds complexity because most >> HTTP libraries provide all the syntactic sugar to send >> "application/x-www-form-urlencoded" >> POST requests. >> You also seem to have missed that PubSubHubbub 0.4 is now agnostic in >> terms of Conten-Type, so it would be rather odd to go back to a time where >> PubSubHubbub only speaks XML :/ >> >> I hope all this helps! >> >> Julien >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> *Got a blog? Make following it simple: https://www.subtome.com/ >> <https://www.subtome.com/> * >> >> Julien Genestoux, >> http://twitter.com/julien51 >> >> +1 (415) 830 6574 >> +33 (0)9 70 44 76 29 >> >> >> On Fri, May 30, 2014 at 5:18 PM, John Anderson < >> [email protected]> wrote: >> >>> There's not been a lot of recent activity on this community list, or >>> even on the PubSubHubbub feed (on SuperFeedr). Who's actively participating >>> in PuSH these days? >>> >>> I've been exploring the spec and commented on a couple Protocol issues: >>> https://code.google.com/p/pubsubhubbub/issues/detail?id=148 >>> and >>> https://code.google.com/p/pubsubhubbub/issues/detail?id=149 >>> >>> I kinda expected at least a brief acknowledgement that someone will look >>> at those. Should I expect to wait a while? (I know you're all probably busy >>> with "real" jobs and such.) >>> Thanks! >>> JSA >>> >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Pubsubhubbub" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "Pubsubhubbub" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Mathieu Robin > Tech Lead Manager, Google Switzerland GmbH > +41 78 696 27 04 > > -- > > --- > You received this message because you are subscribed to the Google Groups > "Pubsubhubbub" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "Pubsubhubbub" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
