W3C home > Mailing lists > Public > public-ws-resource-access-notifications@w3.org > September 2009

[Bug 7478] Eventing: subscription expiration negotiation is incomplete and inefficient

From: <bugzilla@wiggum.w3.org>
Date: Thu, 24 Sep 2009 05:04:08 +0000
To: public-ws-resource-access-notifications@w3.org
Message-Id: <E1MqgUy-000106-MH@wiggum.w3.org>

Oliver Newell <onewell43@gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |onewell43@gmail.com

--- Comment #2 from Oliver Newell <onewell43@gmail.com>  2009-09-24 05:04:08 ---
Is the primary intent of the expiration time to allow the server to gracefully
age out clients subscriptions when clients go away for whatever reason? I think
that was the case with GENA, which was a precursor to WS-Eventing (now limited
to use in UPnP it seems).

My experience is that for the most part clients want data until they no longer
want it, and they will not always be well behaved and do a clean unsubscribe
when they are done. Having an expiration time that is determined server side
and requiring a client to renew ever so often handles this case in a practical
way from the server's perspective. If a client needs an expiration that doesn't
expire, it's not a big burden on a client to have to refresh the subscription
every so often (UPnP device manufacturers typically set the timeout between
15-30 min when they grant subscriptions), and it makes life for the server
implementer much simpler and more manageable. There's no guesswork from the
server perspective trying to figure out if a client is still actively listening
to a subscription or not (which is hard/impossible for middleware that is
connectionless on transmit)

One way to think about it is that the Web scales so well because it is
stateless for the most part. Subscriptions aren't stateless, but at least we
can put a time window on the 'statefullness' to minimize the impact. In my
opinion, that is the intent of the expiration time more so than communicating
information about how long the client actually is interested in the data.
That's almost a separate issue. 

So I guess I would say proceed with caution w/respect to item 3.
With the exception of email-type subscriptions, I would say servers would not
want to support it due to the resource management issue (so errors would be a
common return for that type of request)


Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 24 September 2009 05:04:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:35 UTC