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 ________________________________ 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 >> >
