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