Subject: RE: [Simple] Large response ?

From: "George Foti (QA/EMC)" <[email-masked]>
Date: Thu, 8 Jul 2004 09:40:00 -0500

Isnt it a trade-off of where you put the complexity to repair the document, in the client or in the server.

We need really the requirments to be spelled out to better judge how to proceed.

Rgds/gf

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of Joel M. Halpern
> Sent: Thursday, July 08, 2004 8:48 AM
> To: Miguel Garcia
> Cc: [email-masked]
> Subject: Re: [Simple] Large response ?
> 
> 
> I am sorry.  I can not understand the case where the client 
> can not repair 
> the partial answer, but somehow can get a meaningful answer 
> when it is 
> provided as complete XML elements.  (I presume the example 
> you gave was 
> over-simpilifed, but in the example, there is no anser that will fit.)
> 
> a) If the server sends as much as fits in the "buffer", the 
> client can 
> always parse forward, trim backwards, add closing elements as 
> needed, and 
> end up with more content than would have been shipped if the 
> server had 
> shipped only the elements that it somehow knew would fit.
> b) given that the length of the content of the elements is 
> not known, I do 
> not understand in what terms an element count limit will help 
> a client cope 
> with a resource limitation.
> c) The requirement as you state it seems to edge in to the 
> solution.  I 
> understand that the client software wants to request part of 
> a document.  I 
> understand that to present this to the user the client 
> software will need a 
> well-formed XML document.  I do not understand why it follows 
> that the 
> partial document that is delivered must be well-formed, since 
> the client 
> can work it over any way it chooses.  From the last sentence, 
> you seem to 
> be driving towards a specific implementation.
> d) When we starting putting on constraint about which portions of a 
> document can be requested using this mechanism, and what "schema 
> compliance" is supposed to mean about the answer we are 
> crafting a very 
> specialized solution, rather than tackling a general problem. 
>  And that 
> will make it difficult to build compliant XCAP servers that 
> can cope easily 
> with multiple schemas and schema changes.
> 
> Yours,
> Joel M. Halpern
> 
> 
> In a separate message Miguel Garcia wrote:
> Right. So let's try to formulate the requirement. We are 
> looking for a 
> mechanism that allows an XCAP client to request fractions of an XML 
> document, so that the returned document is valid but need not 
> include all 
> the repeatable entries. This allows the XCAP client to 
> operate on the XML 
> document (render and manipulate it), release the memory, 
> request the next 
> fraction of the same XML document, and start the process again.
> 
> 
> At 09:37 AM 7/8/2004 +0300, Miguel Garcia wrote:
> >Joel:
> >
> >Let me try to give you a concrete example where you can see 
> that the byte 
> >range does not server for the purpose:
> >
> >Imagine I want to request this very simple XML document
> >
> >  <foo>
> >     <bar>This is an element</bar>
> >  </foo>
> >
> >Now, when I request this document, I request a byte range 
> (say, 0 to x 
> >bytes). The server apply the count on the byte range, and cut the 
> >document. It returns me the following document:
> >
> >  <foo>
> >     <bar>This is a
> >
> >So my XCAP client will not consider the document even 
> well-formed, not 
> >even valid. So what can my XCAP client do with this 
> document? I have two 
> >options:
> >
> >a) request the remaining of the document. But since I applied a byte 
> >range, presumably because my XCAP client does not have more 
> available 
> >memory to request a longer document (otherwise, why did I 
> request a byte 
> >range in the first place), I cannot store this partial document and 
> >request the remaining parts (I don't have memory to store 
> the remaining 
> >parts). So this does not solve the problem.
> >
> >b) dispose the document in the garbage bin (a.k.a. release 
> the memory), 
> >and request the complete document. But again we are in the 
> same situation 
> >as in a), the terminal requested a byte range in the first 
> place, so what 
> >for if it has to request the remaining document?
> >
> >Is there any other solution you can envision? I don't, and 
> therefore my 
> >conclusion is that byte ranges does not serve for the purpose.
> >
> >Regards,
> >
> >          Miguel
> >
> >Joel M. Halpern wrote:
> >
> >>There appears to be some (reasonable) desire to get part of an XML 
> >>Configuration, where "part" means not a just selection of 
> identified 
> >>elements but some other subseting.
> >>This appears to be driven by some combination of client 
> memory and user 
> >>presentation resources.
> >>Rather than trying to argue that some solution meets the 
> needs, I would 
> >>like to see a clear and reasonably complete list of 
> requirements.  I can 
> >>believe that there is some requirement that is not met by 
> byte-range for 
> >>example, but I do not know what it is.
> >>Yours,
> >>Joel M. Halpern
> >>
> >>_______________________________________________
> >>Simple mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/simple
> >
> >--
> >Miguel A. Garcia           tel:+358-50-4804586
> >Nokia Research Center      Helsinki, Finland
> >
> >
> >_______________________________________________
> >Simple mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/simple
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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