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.
