hub.mode=query

[Blaine Cook]

While we're throwing new protocol things around, for testing's sake it
would be great to have a hub mode that allowed for querying the status
of a subscription. This is what I've implemented internally and in
tests, but it's definitely open to modification if people think it
should work differently.

======
Subscription status can be checked by the subscriber by making an HTTP
GET request to the hub URL. This request has the following query
string arguments appended:

hub.mode
REQUIRED. The literal string "query"
hub.topic
REQUIRED. The topic URL associated with the subscription.
hub.callback
REQUIRED. The subscriber's callback URL associated with the subscription.
hub.secret
OPTIONAL. The hub.secret value associated with the subscription, if any.

If the request is successful, the hub MUST respond with HTTP 200 OK
and a text/plain response body containing a string representing one of
the following subscription states:

none
The hub has no record of a subscription to hub.topic for the
subscriber at hub.callback
pending
The hub has confirmed the subscription request but is awaiting
approval from the owner of hub.topic
subscribed
The hub is publishing changes of hub.topic to the subscriber at hub.callback

Any other responses MUST be interpreted by subscribers as meaning that
the hub does not support the query mode or is unwilling to provide
information regarding the subscription in question.

Hubs SHOULD NOT violate the privacy of subscribers; unless the
subscriber specified a hub.secret or the hub is operating in
diagnostic mode, the hub MUST respond with HTTP 403 Forbidden and an
empty response body.

[Jeff Lindsay]

I like this. I remember calling for this a long time ago. 

Since "hub.mode" doesn't imply a verb, perhaps "status" would be a more descriptive mode token? Query seems a bit unspecific and might be ever so slightly confusing. I know I was thinking about something different when I saw the subject line here. Also, it's in close proximity to talking about query strings...

-jeff

--
Jeff Lindsay
http://webhooks.org -- Make the web more programmable
http://shdh.org -- A party for hackers and thinkers
http://tigdb.com -- Discover indie games
http://progrium.com -- More interesting things

[Julien Genestoux]

That would be interesting, yes... I agree with Jeff's comment too.

My concern though is that some users may wan to list their subscriptions every 10 minutes, which would eventually be hard on the server if they have 10M... 

[Alexis Richardson]

Are those three states the ONLY states in the lifecycle? I am happy
if they are.

But should we also consider what happens when a subscriber gets
unsubscribed (by any party)? (E.g. 'blocked'?)

Just asking..

a

[Blaine Cook]

2010/1/25 Julien Genestoux <julien.g...@gmail.com>:

> That would be interesting, yes... I agree with Jeff's comment too.
> My concern though is that some users may wan to list their subscriptions
> every 10 minutes, which would eventually be hard on the server if they have
> 10M...

Definitely; my thought is that this is mostly interesting for testing
and debugging purposes. Perhaps some wording to allow the hub to
optionally not support this feature (e.g., if the hub doesn't want to
deal with these requests, it should return HTTP 501)?

b.

[Blaine Cook]

2010/1/25 Alexis Richardson <alexis.r...@gmail.com>:

> Are those three states the ONLY states in the lifecycle?  I am happy
> if they are.
>
> But should we also consider what happens when a subscriber gets
> unsubscribed (by any party)?  (E.g. 'blocked'?)
>
> Just asking..

I used the XMPP XEP 60 states, minus "unconfigured" since PSHB doesn't
have a concept of configuring subscriptions. Since XEP60 is pretty
exhaustive at this point, I didn't feel the need to look further. ;-)

b.

[Alexis Richardson]

Cool ;-)