Re: optimizing container pages serialization to enable streaming

hello eric.

On 2013-11-11, 14:01 , "Eric Prud'hommeaux" <eric@w3.org> wrote:
>The odds that someone who cared about optimizing would use a generic
>serializer are vanishingly small. I'd say that's not a significant
>price. The payload is still text/turtle; no text/turtle parser would
>be able to detect any way that it differs from any rearrangement of
>the same triples.

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?

>Server S1 serializes some LDPC using a generic serializer. Client C
>parses the data, recording each arc in an RDF graph, until it sees the
>membership predicate. At that point, it scans back through the graph
>so far, looking for the membership predicate and acting on each member
>now that it can find them. It continues to parse the network input,
>now in a streaming mode and able to dispatch each member as it arrives
>from the network. Client C has broken no LDP, HTTP, RDF or Turtle
>rules; it has only optimized for the part of the document that follows
>the membership predicate.

i don't think i ever claimed that.

>Server S2 uses a custom serializer which starts out by emitting the
>membership predicate. Client C can consume S2's data much more
>efficiently becaue it can start out in streaming mode. S2 hasn't
>broken any rules, but it is nonetheless, a much more efficient server
>for large collections.

how does s2 signal that c can safely go into streaming mode? or let's put
it like this: if, as a side-effect of defining LDP, there now is some
generic and context-independent way of how text/turtle can be used in a
way that reliably optimizes exchange of (some kind of) ordered RDF-based
data model, then that's nice and should be documented somewhere and then
referenced in the LDP implementation guide.

>I proposed that we say there is exactly one ldp:membershipRules arc
>from the container to the node with all the membership predicate et
>al. That doesn't break any LDP, HTTP, RDF or Turtle rules. Perhaps
>this will meet with less resistance if we simply don't mention that
>serializing that arc at the top of the document will enable more
>efficient streaming parsers. We can let people figure it out for
>themselves.

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.

that's a relatively odd thing to add to a spec, at least in my opinion,
because it creates zero constraints for anybody. which is good because
that's how this discussion started and it seems we're in agreement about
that. so documenting this might be useful, but it might make the spec more
concise to leave it out, and instead move it to the implementation guide.

cheers,

dret.

Received on Monday, 11 November 2013 22:19:25 UTC