W3C home > Mailing lists > Public > public-ldp-wg@w3.org > February 2013

Re: ISSUE-33

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Mon, 11 Feb 2013 11:35:20 -0500
To: Henry Story <henry.story@bblfish.net>
CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Message-ID: <CD3EDBC3.D615%erik.wilde@emc.com>
hello henry.

On 2013-02-11 17:20 , "Henry Story" <henry.story@bblfish.net> wrote:
>On 11 Feb 2013, at 17:09, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:
>>sorry for holding things up a bit about ISSUE-33. i guess i am still
>> wondering what ISSUE-33 is all about. as we have agreed, LDP is about an
>> RDF service surface, so what we serve as resources apart from LDP
>>protocol
>> data can be anything. if we want to encourage people to implement
>>servers
>> that can handle large amounts of data (i.e., large resources), we should
>> look at HTTP range requests and HTTP chunked encoding, and see if there
>>is
>> anything that cannot be accomplished with these mechanisms. if there is
>>a
>> specific RDF paging a server wants to implement, then i guess for LDP it
>> only matters for containers when listing members. for members themselves
>> it is not quite clear to me how pages would map to a proper resource
>> model, if we're splitting up triples into "triple pages" (that's what i
>> understood the non-container paging would be about). but i am still
>> suspecting that i am missing something here, so like eric suggested, a
>>use
>> case and some explanation would be greatly appreciated.
>Erik, I find the idea of doing things on the HTTP level quite interesting
>too. Could you describe or point to a description on how that would be
>done? 

http://tools.ietf.org/html/rfc2616#section-14.5, it's a rather simple
mechanism that allows servers and clients to transfers parts of resources.
very helpful when you download this interesting 4.5gb hires movie and the
transfer stops at 4.3gb. the client can then simply continue with a new
request, instead of having to restart.

cheers,

dret.
Received on Monday, 11 February 2013 16:36:26 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:29 UTC