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

Re: optimizing container pages serialization to enable streaming

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Mon, 11 Nov 2013 20:06:21 -0500
To: "Eric Prud'hommeaux" <eric@w3.org>
CC: Alexandre Bertails <bertails@w3.org>, Linked Data Platform WG <public-ldp-wg@w3.org>
Message-ID: <CEA6A9CB.16BE9%erik.wilde@emc.com>
hello eric.

On 2013-11-11, 15:25 , "Eric Prud'hommeaux" <eric@w3.org> wrote:
>* Wilde, Erik <Erik.Wilde@emc.com> [2013-11-11 17:18-0500]
>>sure. whatever somebody does within the permissible bound of a media type
>> is fair game. but that optimization is not all that interesting when
>> nobody can depend on it and/or ask for it, right?
>No one is depending on it. They are simple able to take advantage of
>it if it's there.

ok, that sounds safe.

>>how does s2 signal that c can safely go into streaming mode? or let's put
>When the client sees the required membership triples, it knows how to
>interpret the graph to date and the rest of the incoming network
>stream. 

so the client uses a LDP-specific parser? again, i would argue that might
be something people easily do in expert circles such as the LDP group, but
for a large-scale protocol, you definitely should count on the vast
majority of clients using off-the-shelf components. if the protocol has
difficulty working when people are doing that, you have a problem. telling
people "just write your own turtle parser" might not solve that problem.

>What I outlined was already true of LDP; as soon as one saw the
>membership triples, one could dispatch the graph and switch to
>streaming mode. There was always going to be an incentive to serialize
>the membership triples first in case there was a streaming client.

true in principle. but hard to deploy if that means telling people that
using off-the-shelf components will cause serious performance problems.

>> 
>> again, that seems like implementation guidance. in spec speak, i guess
>>all
>> you could do is say:
>> 
>> - servers MAY choose to serialize (some) responses this way: ...
>> 
>> - clients MUST NOT rely on servers serializing in the way described
>>above.
>Yup. C's code works both on S1 and S2. It just works better on S2. A
>non-streaming client works identically well with S1 and S2.

ok. let's just make sure we're designing the protocol with non-optimized
clients in mind, not with optimized ones that use custom LDP components
for standard tasks.

cheers,

dret.
Received on Tuesday, 12 November 2013 01:07:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:46 UTC