Subject: RE: [Simple] What is an entrty was (RE: XCAP Directory: Large res ponse ?)

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Tue, 6 Jul 2004 06:28:53 -0500

Miguel you wrote,

> 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, I agree with you on that one. 
But this is not the only assumption that needs to be stated.
Other assumptions.
The user does not in advance how may entries exist in the list in the first place. Is there a way for that information to be available. Otherwise, how would a user to know if he has all the list or not, or how many entires he should retrieve, etc...

> >>   <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:
> >>

Now that makes me ask a second question.
What is an entry from a server point of view ?
Looking back at the example above.
If a user request 3 entries.
Does he get only 2 cause the thirs want is a list or ?????

Rgds/gf

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

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 06 Jul 2004 15:17:36 +0300

George Foti (QA/EMC) wrote:

[snip]

> The user does not in advance how may entries exist in the list in the first place. Is there a way for that information to be available. Otherwise, how would a user to know if he has all the list or…

I agree.

[snip]

> Does he get only 2 cause the thirs want is a list or ?????

I was always thinking of limiting the number of <entry> elements, but 
you are right, there could be a list containing a huge number of <list> 
elements... Hmmm.... At least this problem is only present in the 
presence lists, but not in the XCAP directory (since it is a flat document).

The possible solutions range:

1) I don't care about the problem, limit only the number of <entry> elements
2) Limit both, <entry> and <list>, but independently of each other.
3) Make a joint limit (or range) for both <entry> and <list>

2 has problems, like if I limit each of <entry> and <list> to 50 
elements, I may get up to 100 entries, but it is simple for both the 
client and the server.

3 is the desired solution, but I am not sure on the complexities of the 
design of such alternative.

I guess we need to give it a thought.

- Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland