Subject: Re: [Simple] Issue with comparisons for triggerring

From: "Sean Leahy" <[email-masked]>
Date: Fri, 10 Mar 2006 15:07:56 +0000

Looks good to me - although I still think we do not need the 
struck-through text - it only seems to confuse.

"The <changed> element is used to identify the XML element or attribute, 
from the package specific XML document, whose value MUST change, compared 
to the "previous XML document", in order to activate the trigger and cause 
the content to be delivered.  Previous XML document in this context refers 
to the last XML document that was selected for delivery delivered to that specific subscription before any filter was applied to it." 

Regards,
Sean

Jari Urpalainen <[email-masked]>
10/03/2006 08:55

        To:     ext Sean Leahy <[email-masked]>
        cc:     "Hisham Khartabil <hisham.khartabil", [email-masked]
        Subject:        Re: [Simple] Issue with comparisons for triggerring

Hisham and Sean!

For me the current text is eligible enough although there are some
implicit rules to interpret (and I think I'll understand the intention,
but correct me if my example is wrong ...). If this really needs to be
clarified (which may not be likely given the 48hours state), an example
would be worth a xxx of words:

Given the state can have values A, B or C and a transition from A to C
is the trigger rule:

state | action
---------------
A     | notify (initial subscription)
B     | -
C     | notify
B     | -
C     | -
A     | -
C     | notify
---------------

Similar tables could be given with numbers with <by>. But as I said I'm
contented with the current text although in general I'll prefer good
examples over text (lazy implementer ;-)).
br,
Jari

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: <[email-masked]>
Date: Fri, 17 Mar 2006 11:54:23 +0100

> -----Original Message-----
> From: Jari Urpalainen [mailto:[email-masked]]
> Sent: Friday, March 17, 2006 11:29 AM
> To: ext Hisham Khartabil
> Cc: Burda Michal; [email-masked]
> On Thu, 2006-03-16 at 21:14 +0100, ext Hisham Khartabil wrote:
> > Michal is correct in his observation. The NOTIFY at step 7 should
not
> > be sent. As far as the subscriber is concerned, the is C (receiving
the
> > NOTIFY at step 3). There is no new information given to the
subscriber
> > at step 7 that s/he requested.
> >
> > Hisham
> 
> ok, I was afraid that this wasn't unambiguous enough. So now I must
> change my mind (after re-reading the format i-d) that the text needs
> some clarification, i.e. it should say that the trigger rule is
one-shot
> only (perhaps I was mislead by correspondence with electronics, e.g.
> monostable multivibrator ;-)). But I don't want to argue whether
> multi-shot or one-shot behavior is better...
> 
> br,
> Jari

I can realize use-cases on that "multi-shot" trigger's rules, so IMHO
"multi-shot" is better. Could anyone provide counter-examples to
clarify, why the specification actually proposes the "one-shot"
behaviour?

Pros of "multi-shot" behaviour (actually not supported by specs) follow:

1. Use-case: a user wants to be notified whenever some particular
presentity becomes "online". -- I can imagine an application that waits
for some user's service to become available in order to perform some
action etc.

2. The "Filtering & Throttling paradox" discussed few days ago won't
occur at all.

3. No trigger criteria could cause to "logically terminate" a
subscription - that is, there wouldn't occur the situation where the
subscription exists but no notification is sent ever because of one-shot
trigger that eats all of them.

br,

Michal