Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00

From: [email-masked]
Date: Wed, 04 Jun 2003 04:29:35 -0400

Hisham, Jonathan,

My assumption was the same as that of Hisham. My thoughts were that there would not be a conflict problem as the result of multiple filters on the same document would effectively be combined together to form the output document. We just need to be careful that we don't produce duplicate tuples in the output.

In order to reliably modify, add and delete filters we need to ensure that we can detect and recover from situations when the client and the server get out of sync with what is the current version of the filter document. We either can use some document version numbering scheme or we can use the Hash scheme as Jonathan suggested for this. One advantage as I see of the hash is that it might be easier to use this to efficiently enable the client to select from a set of different baseline filter documents, (e.g the “at work” filters, the “at home” filters, etc) by using hashes of different versions that are stored on the server.  

I suggest that we use an empty ev-filter element for deletion. If the ev-filter element contains a valid id attribute already present in the filter document referenced by the hash and does not contain a What or Trigger element then this filter is removed from the filter document. If the ev-filter with a valid id attribute contains what and/or trigger elements then this indicates that the filter is to be modified to these new settings. If the ev-filter id attribute is new then this filter is added to the filter document. 

TO DELETE:

<ev-filter id = "mess" uri="sip:[email-masked]">
</ev-filter>

TO ADD OR MODIFY:

<ev-filter id = "mess" uri="sip:[email-masked]">
  <what>
   //*[rpids:label="im" or rpids:label="sms" or rpids:label="mms"]/descendant-or-self::*  | //*[rpids:label="im" or rpids:label="sms" or rpids:label="mms"]/ancestor::*
   </what>
 </ev-filter>

A new hash would be calculated for the current state of the filter document.

Andrew

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Jun 2003 09:39:53 -0400

[email-masked] wrote:
> 
> Hisham, Jonathan,
> 
> My assumption was the same as that of Hisham. My thoughts were that
> there would not be a conflict problem as the result of multiple
> filters on the same document would effectively be combined together
> to form the output document. We just need to be careful that we
> don't produce duplicate tuples in the output.

I really dont understand the motivation behind this requirements for 
multiple installed filters in parallel. Why can't you view the whole 
combination as one big filter, and treat that as the thing which is 
managed (i.e., installed, refreshed, deleted)? Just trying to 
simplify. If you make that assumption, the whole problem becomes a lot 
easier.

-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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 04 Jun 2003 09:39:53 -0400

-Jonathan R.