Dew Drop - April 17, 2009 | Alvin Ashcraft's Morning Dew

Dew Drop - April 17, 2009 | Alvin Ashcraft's Morning Dew — Fri, 17 Apr 2009 15:36:01 GMT

PingBack from http://www.alvinashcraft.com/2009/04/17/dew-drop-april-17-2009/

re: Notifications and Subscriptions

Oran — Fri, 17 Apr 2009 23:40:21 GMT

Nice concise post. I think the choice of JSON for the examples helps to make it easy to read and understand.

Even though I wrote a lengthy post exploring how notifications work, I learned some new things from this post. I learned that I can rely on the ETag returned by a new subscription to detect changes. I also learned that notification queues can overflow, and that you can create a new queue by PUTing the watermark to a dead queue.

I think it's important to mention that in steps 3 and 6, the Notifications GET request will park on the server for 25 to 30 seconds before returning with an empty feed. In my opinion, request parking is the coolest feature of notification queues. However, the same request to the local LOE will return immediately. In the case of the cloud LOE, the potential 30-second interval needs to be taken into consideration when renewing the queue based on its TTL. In the case of the local LOE, the immediate return means that, unlike the cloud LOE, you can't afford to poll the local LOE's queue in a tight loop.

The 300-second default queue ExpirationDuration is true for the cloud LOE. The local LOE's default is 600 seconds.

The first paragraph in step 2 is unclear to me. It makes more sense to me if the word "from" is changed to "using".

I take issue with the ability to create a new queue by PUTing the AllSubscriptionsLost watermark to a dead queue. Perhaps there's a good reason to use PUT to create a new queue, but I don't see it. This is a weird way to use HTTP, and the behavior is unexpected and inconsistent. First, the PUT response's Content-Location header contains the original queue's URI which doesn't match the response's SelfLink URI. Second, the queue at the original URI remains dead, you must use the new SelfLink to access the new queue. SelfLinks should remain stable. SelfLinks most certainly shouldn't change as the result of a PUT, especially when the SelfLink in the request is unchanged. I believe it is much simpler to just POST a new queue when you receive AllSubscriptionsLost. The effect is the same, the behavior is more consistent and predictable, and you can delete the weird POST-tunneled-through-PUT logic.

This post doesn't mention the 10-notification paging limit. In practice, users will run into the paging limit long before they run into lost notifications due to queue overflow. Still, I fully agree that users should make it a practice to always post the latest watermark which will make both of these limits irrelevant.

Hopefully this comment doesn't come across as unnecessarily critical. Over all, this is a great post describing a great feature. I would definitely point people here first to learn more about notifications, and then point them to my own post. :-)

http://orand.blogspot.com/2009/03/exploring-live-framework-notifications.html