Subject: RE: [Simple] Urgent: Event Lists Open Issue

From: Adam Roach <[email-masked]>
Date: Mon, 24 Mar 2003 16:08:59 -0600

Ben Campbell [mailto:[email-masked]] writes:

> I have a hard time
> understanding the distinction between applying a filter to the list
> subscription and applying the subscription to the "conceptual"
> underlying subsriptions.

Thinking still of these conceptual underlying subscriptions,
a subscription to a list creates an arbitrarily deep tree
of subscriptions, in which all of the leaves are non-list
resources, and all other nodes are list resources.

Keeping this tree in mind, the question being posed fundamentally
boils down to this: When a filter document is included in a
SUBSCRIBE message to a list, which of these nodes does it apply to?

a) Only the root node?
b) Only the leaves?
c) Everything?
d) Everything but the leaves?
e) Some subset of nodes not listed above?

> For example, is it a question of saying "only tell me when 
> someone moves
> 100 miles" vs. "Tell me when Alice moves 50 mi or Bob moves 75 mi"?

That's interesting, but not really what I had in mind. It also
indicates to me that the model you had in your mind was option
"b) Only the leaves".

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

---

From: Robert Sparks <[email-masked]>
Date: 24 Mar 2003 16:29:02 -0600

So consider this question from the perspective of the
rate-limiting kind of filter. We've asserted earlier
that these kinds of filters aren't event package specific,
so we can carve away solutions that call to individual
packages. The question then becomes do you have to be
able to talk about lists when you express one of these
generic rate limiting filters?

If you place a "No more than once a minute" filter on
a subcription to a list, are you saying

A) I don't want more than one NOTIFY per minute as
   a result of this list subscription.

or

B) I don't want more than one NOTIFY per minute for
   any given leaf in the list/tree.

I think what we have to decide first is whether the
answer is always A or always B, or if the generic rate
filter needs to be able to specify one of those options.

RjS

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Mar 2003 17:30:33 -0500

The answer is A.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Ben Campbell <[email-masked]>
Date: 24 Mar 2003 17:54:41 -0600

> indicates to me that the model you had in your mind was option

No, actually what I had in mind was "a) Only the root.".

Maybe my disconnect is it still feels that the only rational model is
"A) only the root", and options B and C are, among others, possible
mechanisms the root can use to implement that. (Which, by the way, seems
to take us back to my first response.)

Since we seem to be talking _way_ past each other, let me extend your
concrete example. If I only want to see notifies that involve a 100 mi
or more change in geoloc, I express that on my SUBSCRIBE request to the
list. Now, the list server could go about that in a number of ways. It
could delegate subscriptions for each list entry (with real or
conceptual subscriptions), and only pass through notifications when the
threshold is reached. This seems like a clear case of option a).

Now, it could also do this by attaching a derived filter to each
delegated subscription, so that _it_ only sees the changes that match
the rule, and passes them all on to the watcher. That would _seem_ like
option B. But from the watcher's perspective, these two approaches
should be indistinguishable.

I guess my point is, it seems to me this should be specified based on
what goes into the root subscription, and what comes back out--which
should be doable without explicitly dealing with filters in the list
draft, just as it is without explicitly reving 3265.

---

From: Ben Campbell <[email-masked]>
Date: 24 Mar 2003 17:59:29 -0600

> filter needs to be able to specify one of those options.

OK, I can buy that--but that example is of exactly the same form as one
I gave for geoloc, to which Adam responded that was not the question.
So, how is that question different from saying " Notify me whenever any
list member moves 100 mi" vs "Notify me when a particular member moves
more than 100 mi"?

The problem underlying both of our examples seems to be one of filter
rule expressivity, and I don't understand why that decision needs to be
made in the list draft.