Issue with comparisons for triggerring

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
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple

On Fri, 2006-03-10 at 14:26 +0100, ext simple-bouncesietf.org
wrote:
> 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
> 
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



_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple