Thanks for the detailed answer, Paddy. I'll probably have to build a similar system to yours. Although it does show that un-subscribing is actually not as easy as it sounds. I still think that a simple update to the specs could save future users having to write the extra functionality that we're writing. But I'm not going to talk about this anymore :)
Waleed On Wed, Feb 17, 2010 at 4:10 AM, Pádraic Brady <[email protected]>wrote: > Hi Waleed, > > I hate to be the one that says this, but isn't this an implementation > issue? The protocol as is works fine wherever I've used it. It sounds as if > the problem is that your application's architecture doesn't possess enough > accessible/flexible points to hook in the protocol's mechanism. For example, > why is retrieving the feed URI difficult? In my own apps, any subscription > is linked back to source blog/feed records using the feed ID (often a URI) > and Blog URI and also stores the Hub's URI on the same table. This is > completely redundant, of course, but it's by design since I don't link > subscriptions to any other table via foreign keys (it's a self-contained > system for simplicity). It also carries a simple flag carrying a state of > "active", "inactive" and "to_delete". > > With those bits of information persisted (even when the blog, feed and all > entry records are deleted), I can use a small maintainance script (via cron > or similar) and the existing callback logic to ensure the subscription > (marked "to_delete") is unsubscribed. I also unsubscribe at the point of > deleting the blog/feed, but having a backup never hurts to cover any Hub > downtime. If it isn't subscribed in a timely way (I also check modification > date), I can simply purge the record on the assumption the relevant Hub is > "having issues" ;), though this is a last resort and far from ideal. > > The main thing here is identification and verification - deleting the blog > should not make a subscription anonymous to your application, and you can't > rely on a single unsubscribe and so should have a backup maintainance > process to verify unsubscriptions and retry them if necessary. These seems > to be some of the core problems you're having, i.e. in suggesting the Hub > forward the ID points of hub_url and topic_url. I use the same two points as > the subscription's unique ID for the database, and the hash of both > concatenated as the identifier appended to my callback URI. The simple > result being that using any callback URI, I can immediately look up all the > URIs involved. > > I'd also be wary of letting subscriptions time out naturally, I know of at > least one Hub where subscriptions can hang around for a long time so there's > no guarantee any one Hub will actually timeout a subscription by themselves. > In any event, what is stopping a Hub from setting a large validity window? > At that point you're just throwing away server resources since inevitably > all of these will keep sending requests that need to be checked against the > subscription store before you even know that they should be ignored. It may > sound negligible, but people forget the callback is often embedded in the > main app's framework which can be costly in its own right. > > Hopefully this isn't too critical ;). The protocol just doesn't address the > nuts and bolts of actual implementation, so this is just a vague overview of > how I solved similar problems to the ones you seem to be describing. Maybe > it will of some help though. > > Paddy > > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > OpenID Europe Foundation Irish Representative<http://www.openideurope.eu/> > > > ------------------------------ > *From:* Waleed Abdulla <[email protected]> > *To:* [email protected] > *Sent:* Wed, February 17, 2010 11:27:36 AM > *Subject:* Re: [pubsubhubbub] Proposal: An easier way to unsubscribe > > Sure, I'm for keeping the specs simple. I just wanted to share a practical > obstacle I encountered while implementing the specs, and it's up to you guys > to decide if it's worth doing anything about it. > > I did spend a few hours today implementing the unsubscribe functionality. > And, yes, I know, it should theoretically take no more than 10 minutes, but > my system is complex and the parts that handle subscribing are different > from the parts that handle un-subscribing. The problem I faced was that when > I get an update from the hub, it doesn't include the topic URL with it. I do > include an identifier of the blog in the callback URL, but if the blog has > been deleted from my system, then the only way to find the topic URL is to > parse the feed and extract the "self" link. This works most of the time, > except when the feed is malformed. In which case, there is not much I can do > other than letting the subscription expire on it's own. > > This brings me to another suggestion: it would be super nice if the hub > sends the hub_url and topic_url as headers in the POST so it's easier to > tell where the update is coming from. > > Regards, > Waleed > > > > > > On Tue, Feb 16, 2010 at 9:50 AM, Bob Wyman <[email protected]> wrote: > >> On Mon, Feb 15, 2010 at 6:57 PM, Waleed Abdulla <[email protected]> wrote: >> >> > What if, as a subscriber, when I receive a ping >> > for a feed that I don't care about anymore, >> > I simply reply with the word "unsubscribe" >> > in the body to tell the hub to get me off the list? >> While your proposal sounds pretty easy, it would make the PSHB >> specification more complex while not really adding any more capability to >> the system. My personal preference would be to keep the core specification >> as simple as possible and only increase its complexity when doing so >> actually delivers new capabilities. >> >> bob wyman >> >> On Mon, Feb 15, 2010 at 6:57 PM, Waleed Abdulla <[email protected]> wrote: >> >>> Hey everyone, >>> While implementing PubSubHubbub and using it in production, I >>> realized that there are several situations in which I need to un-subscribe >>> from a feed. Per the specs, the right approach, is to send an unsubscribe >>> request. While this works, there could be an easier way: What if, as a >>> subscriber, when I receive a ping for a feed that I don't care about >>> anymore, I simply reply with the word "unsubscribe" in the body to tell the >>> hub to get me off the list? >>> >>> When I receive a ping, I have to check it out and decide what to do >>> with it, and that's the perfect time to decide if I want to unsubscribe. By >>> making it super easy to unsubscribe, I believe we'll have less pings that >>> get ignored because the subscriber can't be bothered to send a proper >>> unsubscribe request. Thoughts? >>> >>> Regards, >>> Waleed >>> >>> >> >
