My favorites | Sign in
Project Home Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 36: Better define the subscribe side of protocol, requirements it places on the hub
8 people starred this issue and may be notified of changes. Back to list
Status:  New
Owner:  bslatkin


Sign in to add a comment
 
Project Member Reported by bslatkin, Jul 19, 2009
SUMMARY:

When verification fails, serve the requesting subscriber a 409. This lets
them test the success of their own subscription.

RELEVANT SECTION: 6.1

COMMENT/REQUEST:

The reference hub implementation returns returns 409 if a subscription
verification fails in sync mode. This is great and should probably be
in the spec so there is a standard way subscribers (or subscriber
agents) can know if verification failed. This would mean if they want
to know, they would not use async mode.

Aug 4, 2009
#1 tonygarnockjones
Why 409 ("Conflict") rather than 403 ("Forbidden")?
Sep 3, 2009
Project Member #2 bslatkin
Further questions that are related:

From Mark Smith:

> One thing I don't see in the spec is if a hub is required to persist
> subscriptions to some data store.  I can easily see someone
> implementing an in-memory hub (I believe the Python Twisted
> implementation a while back is like this) that doesn't save
> subscriptions, and as a subscriber, we don't know that a hub has lost
> our state or not.
>
> Is this something you intend to codify in the spec, or is it up to
> particular hubs?  (And in that case, what is the reference hub on
> GAE's policy?  If I specify 30 days as my lease, can I depend on that
> actually working?)

From Jeff Lindsay:

> Anyway, I'm not entirely sure it's necessary for the spec, at least as a
> requirement. It definitely needs to be stated clear if they are not
> persistent in any implementation ... but this is an interesting issue. You
> can definitely say an implementation needs to honor subscription lease, but
> it can't honor it if it's not running... I think that's implied ... it's
> interesting because most specs are about interfaces, not the state behind
> them.
Summary: Better define the subscribe side of protocol, requirements it places on the hub
Sign in to add a comment

Powered by Google Project Hosting