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...
On Mon, Jan 25, 2010 at 2:30 AM, Jeff Lindsay <[email protected]> wrote: > 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 > > > On Sun, Jan 24, 2010 at 5:19 PM, Blaine Cook <[email protected]> wrote: > >> 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 > 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 >
