Re: Proposal for containers

hello all.

On 2013-01-31 9:51 , "Henry Story" <henry.story@bblfish.net> wrote:
>On 30 Jan 2013, at 16:23, Ashok Malhotra <ashok.malhotra@oracle.com>
>wrote:
>>D. If you GET all members of a
>> container that has nested components, you get all the contents,
>> members and containers at the top level.  That is, you do not get nested
>> components.
>That is also very vague. I assume you mean "If you GET an LDPC resource"..
>yes, that is how one expects containers to behave, but
>I think that is somewhat beyond the scope of what needs to be defined.
>When you GET a LDPC you get information about its contents (LDPRs and
>LDPCs, 
>and other). Minimally, you could get just a link to the members. Of course
>the risk is that in order to work out what these are pointing to
>a client would have to download each resource to find out.  So it is a
>pragmatic thing to do to give some of the metadata needed for each
>resource.

i think what ashok was saying was that if you GET a container, expect to
GET representations of that container and its entries, which can be
members or other containers. but do not expect to also GET the
representations of these containers' content. instead, you'll find a link
and if you follow this, you will GET that additional info. at least that
was how i understood it, essentially a definition of where the graph you
GET is cut of and instead contains links, and then the protocol tells you
what you'll GET when you follow those links.

if i understand this correctly, then this will need to be defined by the
protocol, because it defines the extent of the representations that are
served (which graph to you GET), and those that are made available for
subsequent protocol interactions (which links will you find to GET more
information about things that were cut off in the previous representation).

cheers,

dret.

Received on Thursday, 31 January 2013 10:26:43 UTC