- From: David Snelling <David.Snelling@UK.Fujitsu.com>
- Date: Tue, 5 Oct 2010 13:11:25 +0100
- To: Doug Davis <dug@us.ibm.com>
- CC: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <95F567B7-CB88-42B7-8BE0-2FCA7E899A01@UK.Fujitsu.com>
Folks,
I'm not sure where all this is going to end, but we at least need to remove the use of "indefinite":
From Wiki:
indefinite (comparative more indefinite, superlative most indefinite)
Without limit; forever, or until further notice; not definite.
Vague or unclear.
Undecided or uncertain.
(mathematics) An integral without specified limits.
From Oxford Concise:
indefinite - adj.
Not clearly expressed or defined; vague.
> lasting for an unknown or unstated length of time.
From Doug's Book of Spec Words:
indefinite - adj.
"dunno".
On 5 Oct 2010, at 02:03, Doug Davis wrote:
>
> Gilbert Pilz <gilbert.pilz@oracle.com> wrote on 10/04/2010 07:06:25 PM:
> > I think that the problem with both the current spec and your
> > comments below is that the way the terms "expire", "expiration" etc.
> > are used is conflating two separate concepts. One of them (which you
> > refer to as the "expiry feature") concerns the resource management
> > strategy employed by the subscription manager to manage the
> > resources associated with a subscription; the idea that every
> > subscription will be automatically cleaned up a specific, known time
> > etc. The other concerns the existence (or lack thereof) of an agreement
> > between the subscriber and the subscription manager as to if/when
> > the subscription will be automatically deleted. This conflation of
> > these two ideas is causing problems.
>
> Do you purposely say "automatically cleaned up" in one spot and
> "automatically deleted" in another? I'm just curious if they
> mean the same thing or not. To me they do so I'll assume they do
> to you too.
>
> To me you can't separate these two as part of the protocol. W/o the
> "automatic cleanup" due to a timeout feature, you have no need for the
> Expires element at all. Said, another way, if Subscriptions were never
> "automatically cleaned-up" due to time, and people had to call Unsubscribe,
> there wouldn't be the need for this negotiation at all.
>
> > First, there is no reason for a subscriber to want or need to know
> > anything about the resource management strategies used by the
> > subscription manager. Any attempt to communicate this information
> > represents a hole in our abstraction of a subscription manager - a
> > hole that can only cause misunderstandings and interoperability
> > problems.
>
> The only reason to not communicate this information is if it doesn't
> matter. But knowing when a Subscription will be "automatically
> cleaned-up" could be vital to a subscriber otherwise they'll never
> know when to call Renew.
>
> Your first sentence is very confusing to me. If we accept the notion
> that Expires in some form needs to remain (which I think everyone will
> agree to), then how can a subscriber not want/need to know what the
> resource management strategy is? At least w.r.t. this notion of
> "automatic cleanup" due to time. That's really all Expires is about.
> Remove the desire to explain _when_ this "automatic cleanup" will happen
> and you remove the need for Expires. Unless you don't consider
> "automatic cleanup" due to tie to be part of the "resource management strategy".
> (I discuss this "part of" notion a bit later on)
>
> > For an example, consider the disconnects around the use of
> > the phrase "indefinite" and the value "PT0S". Some people seem to
> > think it means "never", others "a really, really long time" and
> > others simply "you don't know". The idea of an "indefinite
> > expiration" is both useless and dangerous.
>
> Aside from some of our private IMs, I've never heard anyone refer to it
> as "you don't know". And "never" and "a really, really long time" are, for
> our purposes, the same thing. If there are words in the spec to imply
> that PT0S/indefinite means "dunno" then we need to fix that because that
> level of uncertainy is asking for an interop problem. Can you show me
> where in the spec "dunno" might be implied? I find text like this:
> If this element does not appear, then the subscription will not
> expire. That is, the subscription has an indefinite lifetime. Likewise,
> a value of PT0S indicates that the subscription will not expire.
> Which is pretty clear to me that its not "dunno".
>
> > Secondly, we have to keep in mind that there are many different ways
> > to manage the resources associated with a subscription. One strategy
> > could be to simply monitor the level of various critical resources
> > and, when these reach a low water mark, start deleting subscriptions
> > on a least recently used basis. A subscription manager that
> > implements this strategy can not tell you when, or even if, it is
> > going to "expire" a subscription - whoever implemented it probably
> > wasn't even thinking in those terms. It's simply not true to say
> > that "all subscription managers implicitly support the notion of expiry".
>
> This is mixing topics. While a Subscription Manager may choose to
> have this kind of resource management code, this is separate from the
> "automatic cleanup" code that is tied to the Expires element. And
> it would be a mistake to call this kind of cleaning up "subscription
> expiring" - at least per the current spec's use of the term. Today,
> the Expires element and the notion of "expiry" are all based on time.
> Yes there may be other factors when determining when to "automatically
> cleanup" a subscription, but those are out of scope of the spec and
> the expiry feature (and therefore the Expires element).
>
> It seems to me that the real issue coming from this "low water mark"
> type of example is whether or not it triggers the EndTo processing,
> not how its related to Expires/expiry/timeout. Think of it this way...
> there are potentially many ways a Subscription could be deleted.
> Unsubscribe and "expiry" are just two of them. Each of these are
> well defined in terms of what the protocol elements mean w.r.t.
> this part of the resource mgmt code. This doesn't mean there couldn't
> be other aspects of the resource mgmt code - it just means we're not
> touching on them in the spec. Section 4 of the spec include this:
> In addition, the Event Source/Subscription Manager MAY cancel a
> subscription at any time, as necessary.
> I think your "low water mark" example falls into that category. I
> just don't know if it is considered "unexpectedly" and should
> trigger the EndTo processing - or not. Perhaps the spec needs to
> clear that part up? I'm leaning towards saying it should trigger
> it since its deleting the Subscription for reasons that are not
> covered by the spec, but if some extension defines it in such a way
> as to make this trigger "expected" to a Subscriber then we're back
> to not triggering EndTo. Sigh.
>
> > I think that, to be of any use at all, we need to narrow down the
> > definition of "expiration" to refer to "the agreement between the
> > subscriber and the subscription manager on when then subscription
> > will be automatically terminated".
>
> To me it already means this and I'm still not clear on where in the
> spec it implies anything else.
>
> > We might even want to change all
> > occurrences of the English word "expiration" to "subscription
> > expiration". This is analogous to the stock trading term "stock
> > option". In English, the word "option" means very loosely "the
> > right/ability to do something", but in context of equity trading a
> > "stock option" refers to an explicit, legally binding agreement
> > between two parties. We need the term "subscription expiration" to
> > have the same flavor.
> >
> > Finally, we need to reduce the number of ways that the WS-Eventing
> > protocol signals the existence (or lack thereof) of subscription
> > expiration agreement.
>
> I'm not following this. The presence or absence of the Expires element
> has no impact on whether there is an agreement around expiration.
> Per the spec today, the absence of the Expires element implies PT0S.
> If this element is not present, the implied default expiration time
> is indefinite. A value of PT0S indicates a request for an indefinite
> expiration time.
> This means that it has the same semantics as Expires+PT0S. While this
> does mean that there are two ways of saying the same thing, I don't
> think this it introduces any confusion around the expiry feature.
> We can remove the optionality of the Expires element if that helps, but
> to me it was always just a handy short-hand notation.
>
> Likewise, we have similar text for GrantedExpires. Its absence is
> equivalent to its presence+PT0S.
> If this element does not appear, then the subscription will not
> expire. That is, the subscription has an indefinite lifetime. Likewise,
> a value of PT0S indicates that the subscription will not expire.
>
> It may be confusing to some people that the text we use in each of
> these cases is slightly different:
> will not expire
> indefinite lifetime
> indefinite expiration time
> expiration time is indefinite
> and we can be more consistent if that helps.
>
> > I think the following should apply:
> >
> > 1. If the subscriber has no interest in whether/if the subscription
> > will be automatically deleted, it does not include the Expires
> > element in the Subscribe request. In such cases the subscription
> > manager MUST NOT include the GrantedExpires element in the
> > SubscribeResponse. The end result will always be that there is no
> > subscription expiration. If EndTo was specified, the subscription
> > manager MUST send a SubscriptionEnd message if/when it automatically
> > deletes the message since there was no way for the subscriber to
> > know if/when this was going to happen.
>
> I'm not in favor of introducing the notion of a subscriber having
> "no interest in whether/if the subscription will be automatically
> deleted". Back in our MEX discussions we argued to remove the "whateva"
> dialect - I'm not in favor of adding a "whateva" Expires time in
> WS-Eventing. :-) In this case, as silly as it may sound, someone
> can choose to make all "whateva" subscriptions exactly 1 second long
> and be spec compliant. I have no idea what Subscriber would ever
> actually ask for this kind of randomness. As you say later on,
> if they really don't have a preferred timeout then they can use
> @BestEffort with some Expires time.
>
> > 2. If the subscriber needs to know whether/if the subscription will
> > be automatically deleted, but doesn't wish to "bid" a particular
> > time, it includes the Expires element with a value of "PT0S". If the
> > subscription manager knows or can figure out if/when the
> > subscription will be automatically deleted, and it wishes to share
> > this information with the subscriber (i.e. it supports the
> > negotiation of a subscription expiration), it accepts the request
> > and indicates that time via the GrantedExpires element in the
> > SubscribeResponse.
>
> Now you're introducing quite a bit of ambiguity. You've made PT0S mean
> "don't care" and "live forever". You've also introduced this notion
> of "wishing to share" - this should never be an option. Short hand
> notations is one thing - but saying "dunno" is something very different and
> not something we have in the spec today and I'm not infavor of adding it.
>
> > GrantedExpires MUST NOT use the value PT0S, as
> > that doesn't tell the subscriber anything useful.
>
> I disagree that GrantedExpires/PT0S isn't useful. Its very clear that
> the Suscription will not expire. This says nothing about other
> subscription mgmt logic - it just touches on the timeout part of it.
>
> > If the
> > subscription manager either can not or will not tell the subscriber
> > when the subscription will be automatically deleted (i.e. it does
> > not support the negotiation of a subscription expiration) it
> > generates the wse:ExpiresNotSupported fault.
>
> Disagree with this too. We're asking for an interop problem if
> the two sides are not clear on when a subscription will be deleted
> due to this timeout/expiry logic. Even if its to say "it won't be".
>
> Overall I disagree that anything in the spec today introduces the
> concept of not caring about this timeout stuff, or not negotiating it.
> And I think it would be a mistake to introduce it now. Even missing
> elements that imply "never expire" are still negotiating are
> communicating the agreed to values of the timeout.
>
> It would really help me if we could back this discussion up and
> you could point out the parts of the spec that are unclear or
> introduce the ambiguity you're concerned about. I don't see
> where it says "no Expires", or PT0S, means "dunno".
>
> As I said above, if the terms we use in some spots need to be
> tweaked then we should do so - but regardless of the wording
> we're using I think the intent was that the absence of the
> Expires/GrantedExpires elements (and PT0S) means "will not be
> deleted due to time".
>
> -Doug
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
Fujitsu Laboratories of Europe Limited
Hayes Park Central
Hayes End Road
Hayes, Middlesex UB4 8FE
Reg. No. 4153469
+44-7590-293439 (Mobile)
______________________________________________________________________
Fujitsu Laboratories of Europe Limited
Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
Registered No. 4153469
This e-mail and any attachments are for the sole use of addressee(s) and
may contain information which is privileged and confidential. Unauthorised
use or copying for disclosure is strictly prohibited. The fact that this
e-mail has been scanned by Trendmicro Interscan does not guarantee that
it has not been intercepted or amended nor that it is virus-free.
Received on Tuesday, 5 October 2010 12:11:59 UTC