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

From: <[email-masked]>
Date: Fri, 10 Mar 2006 14:26:12 +0100

Jari wrote:
> Looks like you are proposing 6 ;-). If I were to implement this (which
> is btw. quite challenging), I would probably maintain only one
document,
> and the "trigger state" per watcher could be kept e.g. within the
> watchers filter rule document, i.e. it could be e.g. an additional
> attribute value within the <changed> element. But this is of course an
> implementation issue. So imo keeping this "state information" does not
> mean that you have to maintain the full published information.
> Definitely this is additional state information to remember but I
doubt
> that it is not a major issue considering all the other tasks that you
> have to implement. Another story is whether the text needs
clarification
> or not.

In my opinion, it does not last to store the "trigger state" only. If
the filtering would be implemented as proposed, I am convinced we need
to store the whole "old" notifications because of partial publications
creation.

BR,

Michal Burda

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

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 10 Mar 2006 16:29:13 +0200

> to store the whole "old" notifications because of partial publications
You mean partial notifications ? Combination of these two is certainly
another story as they are two separate issues. Partial notification only
patches the last event state which must be stored somehow, of course per
subscriber and e.g. auto diffing is applied after filtering. I would
probably store this last state (==1 doc/subscriber) because it seems the
most trivial. The thread however, is about how triggering works with
filtering.
br,
Jari