Subject: RE: [Simple] RE: XCAP Directory: Large response ?

From: [email-masked]
Date: Tue, 6 Jul 2004 14:38:54 +0300

I think extending XCAP to enable this feature is limiting and only works for XCAP. A better solution would be to create a general HTTP solution.

I acknowledge that the filter stuff as it is defined now does not allow you to do what you want, but we can extend it in a similar way Jonathan proposed to extend XCAP. I.e. Allow the filter to carry the position() function. The example I gave therefore becomes:

   GET ...

   <?xml version="1.0" encoding="UTF-8"?>
   <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
     <filter id="8439" uri="sip:[email-masked]">
       <what>
         <include>
           //resource-lists/list[@name="friends"]/entry[position() > N and position() < M]
         </include>
       </what>
       </filter>
   </filter-set>

Regards,
Hisham

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]]
> Sent: 06.July.2004 13:51
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: Jonathan Rosenberg; George Foti (QA/EMC); [email-masked]
> Subject: Re: [Simple] RE: XCAP Directory: Large response ?
> 
> 
> Well, the benefit is clear to me. Let's assume you can 
> accommodate 100 
> resources in a device. You get resources 1-100, do some xcap 
> operation 
> (add, delete, modify), then you can release your memory and get 
> resources 101-200, and so on.
> 
> Think for a second that this is something similar to browsing your 
> e-mails through a web interface. All the applications I am aware of 
> allow you to do some pagination. They return a valid HTML code with a 
> range of messages of your inbox. The key feature is to avoid 
> flood your 
> browser and get the user bored scrolling down over 1000 messages.
> 
> - Miguel
> 
> Khartabil Hisham (Nokia-TP-MSW/Helsinki) wrote:
> 
> > I really wonder what the benefit is from such feature. If 
> there are 1000 resources in a resource list and I can only 
> fit 100 due to memory limitations in my device. What would it 
> mean for me to get the first 100, the 2nd 100 or the 
> resources between 500 and 599?
> > 
> > I would rather prefer a feature where I can select the 
> resources I want to get, if they are indeed on the list. 
> That's why I was suggestion an event-filter like approach we 
> I select the resources explicitly.
> > 
> > I gave an example on this in a separate thread, but I copy 
> it again here:
> > 
> >    GET ...
> > 
> >    <?xml version="1.0" encoding="UTF-8"?>
> >    <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
> >      <filter id="8439" uri="sip:[email-masked]">
> >        <what>
> >          <include>
> >            
> //resource-lists/list[@name="friends"]/entry[@uri=""[email-masked]"]
> >          </include>
> >          <include>
> >            
> //resource-lists/list[@name="friends"]/entry[@uri=""alice@exam
> ple.com"]
> >          </include>
> >        </what>
> >        </filter>
> >    </filter-set>
> > 
> > 
> > So a filter is used to GET the resources a client is 
> interested in, if they are present on the list.
> > 
> > /Hisham
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
> >>[mailto:[email-masked]]On Behalf
> >>Of ext Miguel Garcia
> >>Sent: 06.July.2004 10:16
> >>To: Jonathan Rosenberg
> >>Cc: George Foti (QA/EMC); [email-masked]
> >>Subject: Re: [Simple] RE: XCAP Directory: Large response ?
> >>
> >>
> >>Summary of the thread:
> >>
> >>- I think we have consensus on adding a feature that allows an XCAP 
> >>client to request a range of XML elements in a particular schema.
> >>
> >>- It seems that the HTP Range header does not serve for the 
> purpose, 
> >>since it operates on bytes and will most likely truncate XML 
> >>documents.
> >>
> >>- It seems that the XPath position() operator will almost 
> >>serve, but it 
> >>is not part of the XCAP base specification.
> >>
> >>- And we don't want to delay the XCAP base spec by adding 
> >>more features 
> >>at this stage.
> >>
> >>- So this feature can be added as an advanced XCAP feature at 
> >>a later stage.
> >>
> >>So far so good. At least I agree with the above. There is one 
> >>bit where 
> >>I don't quite agree: it seems that the position() opeator in XPath 
> >>operates on the element level, meaning that if we have a 
> >>non-flat list, 
> >>the XCAP client will need to request ranges in each of the 
> lists (see 
> >>point 2 below).
> >>
> >>I think this is bad, and since we are going to design this extended 
> >>feature, we should make it simple to use.
> >>
> >>First, if I have a device that can accommodate x entries, my 
> >>XCAP client 
> >>would need to request x entries for the first list, get the 
> response 
> >>(say y entries came), then do a new query requesting x-y 
> >>entries in the 
> >>next list, etc. Alternatively, my XCAP client can request x 
> >>entries en 
> >>each list, and perhaps I will get n * x entries (n is the 
> >>number of lists).
> >>
> >>Second, this way of working assumes that I know in advance 
> >>the number of 
> >>lists that are nested. This assumption is false when I have never 
> >>downloaded the XML document (such as when I start using a 
> new device).
> >>
> >>In short: I want to have the means in XCAP to indicate: 
> >>"please send me 
> >>this XML document with range of x to z entries, and send them 
> >>to me in a 
> >>valid XML document". I don't need to know the structure of 
> >>the document 
> >>in advance (how many deep nested lists and their names), 
> >>although I know 
> >>the XML schema of the document.
> >>
> >>Is this something we can agree upon?
> >>
> >>- Miguel
> >>
> >>Jonathan Rosenberg wrote:
> >>
> >>
> >>>inline.
> >>>
> >>>Miguel Garcia wrote:
> >>>
> >>>
> >>>>>XCAP doesnt support that level of complexity in the 
> server. If it 
> >>>>>did, and you wanted protection against memory overload 
> >>
> >>(say, 1k max), 
> >>
> >>>>>you'd do something like this:
> >>>>>
> >>>>>GET http://server/blah-blah/list/buddy[position() > N and 
> >>
> >>position() 
> >>
> >>>>>< M]
> >>>>>Range: bytes=0-1000
> >>>>>
> >>>>>If the response is truncated, then you need to adjust 
> >>
> >>your pagination 
> >>
> >>>>>size on the client.
> >>>>>
> >>>>>-Jonathan R.
> >>>>>
> >>>>
> >>>>I think this is going in the right direction now. So let me ask a 
> >>>>couple of questions to verify that the position() is 
> valid for the 
> >>>>purpose we want.
> >>>>
> >>>>1) Is position already part of XCAP? By reading the XCAP 
> >>
> >>base document 
> >>
> >>>>I guess the answer is yes.
> >>>
> >>>
> >>>No, it is not. I would not suggest putting this in the base 
> >>
> >>spec, which 
> >>
> >>>is already overdue and suffering feature creep. I have 
> >>
> >>suggested, in 
> >>
> >>>another thread, that we perhaps can have an "xcap advanced 
> >>
> >>operations" 
> >>
> >>>spec that extended xcap with new features, including multiple 
> >>>insertions. This would possibly be a candidate feature for such an 
> >>>extension, if the group decided to pursue that.
> >>>
> >>>
> >>>
> >>>>2) I guess if we have a non-flat list, the position element will 
> >>>>operate  in all the leaves of the XML document. For 
> >>
> >>instance, if we 
> >>
> >>>>have a resource list document, with several <list> 
> >>
> >>elements, each one 
> >>
> >>>>containing a few <entry> elements, the position() 
> >>
> >>predicate executed 
> >>
> >>>>in the <entry> element will consider the <entry> element 
> >>
> >>sequentially 
> >>
> >>>>ordered.
> >>>
> >>>
> >>>No. It would apply only at the specific place in the 
> >>
> >>hierarchy where it 
> >>
> >>>is placed.
> >>>
> >>>
> >>>>Let me try to explain better with an example. Consider the 
> >>
> >>following 
> >>
> >>>>resource list XML document.
> >>>>
> >>>>  <list name="friends" uri="sip:[email-masked]" 
> >>>>subscribeable="true">
> >>>>    <entry name="Bill" uri="sip:[email-masked]">
> >>>>      <display-name>Bill Doe</display-name>
> >>>>    </entry>
> >>>>    <entry name="Johanna" uri="sip:[email-masked]">
> >>>>      <display-name>Johanna Doe</display-name>
> >>>>    </entry>
> >>>>    <list name="close-friends" uri="sip:[email-masked]"
> >>>>          subscribeable="true">
> >>>>      <entry name="Joe" uri="sip:[email-masked]">
> >>>>        <display-name>Joe Smith</display-name>
> >>>>      </entry>
> >>>>      <entry name="Nancy" uri="sip:[email-masked]">
> >>>>        <display-name>Nancy Gross</display-name>
> >>>>      </entry>
> >>>>      <entry name="Peter" uri="sip:[email-masked]">
> >>>>        <display-name>Peter Black</display-name>
> >>>>      </entry>
> >>>>      
> >>
> >><external>http://www.example.org/xcap/resource-lists/users/a/foo
> >>
> >>>>         </external>
> >>>>    </list>
> >>>>  </list>
> >>>>
> >>>>There are 5 <entry> elements, named Bill, Johanna, Joe, Nancy and 
> >>>>Peter. Imagine I want entries 2 to 4 (in spite they span across 
> >>>>different lists). Will the HTTP URI be something like:
> >>>>
> >>>>GET 
> >>>>
> > 
> > 
> http://server/blah-blah/resource-lists/users/jack/entry[position()>1 
> > 
> >>>and position()<5]
> >>
> >>
> >>No, this will not work. I would suggest that, if you are 
> worried about 
> >>this, the client would page in each level of the hierarchy 
> at a time.
> >>
> >>
> >>
> >>>3) I believe the HTTP byte ranges is a complement of this 
> feature, a 
> >>>kind of emergency life jacket that under normal 
> circumstances will not 
> >>>be use. I doubt an XCAP client can do much with an XML 
> document that 
> >>>is truncated by the byte ranges: it can just discard the 
> contents or 
> >>>store them (if it has enough memory) and request the rest of the 
> >>>document.
> >>
> >>
> >>Right. The problem Ranges solves is if a fixed memory is 
> available in 
> >>the device for the content, you can make sure that there is room to 
> >>store the results. If the results are a truncated document, 
> you would 
> >>need to retry with a much smaller page size.
> >>
> >>-Jonathan R.
> >>
> >>
> > 
> > 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
> 
> 

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

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 06 Jul 2004 14:54:07 +0300

Hisham:

I agree that the filter function could be extended, but I doubt it could 
be generally be useful for HTTP, since it requires the document to be 
written in XML.

At the end of the day, it is the same to carry a filter that indicates 
how many entries should be return, than carrying the request itself in 
the URI as a position predicate. Honestly, I think it is simpler to use 
the position predicate in the URI than all the burden of a filter 
criteria document.

Don't missinterpret me. Filters are important for long lived SIP 
subscriptions, but I don't see the point in every HTTP (XCAP) request 
carring a filter criteria document to be applied to the response.

- Miguel