Re: optimizing container pages serialization to enable streaming

hello eric.

On 2013-11-11, 15:25 , "Eric Prud'hommeaux" <> wrote:
>* Wilde, Erik <> [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

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



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