On Thu, Jul 28, 2016 at 09:16:18AM +0200, Lars Schneider wrote:
> But Peff ($gmane/299902), Duy, and Eric, seemed to prefer the pkt-line
> solution (gmane is down - otherwise I would have given you the links).
FWIW, I think there are arguments for transmitting size + content
(namely, that it is simpler); the downside is that it doesn't allow
streaming.
So I think there are two viable alternatives:
1. Total size of data in ASCII decimal, newline, then that many bytes
of content.
2. No size header, then a series of pkt-lines followed by a flush
packet.
And you should choose between the two based on whether it's more
important to allow streaming, or more important to make the filter
implementations simple[1].
Any solution that is in between those (like sending a size header and
then using pktlines anyway) is sacrificing simplicity but not getting
the streaming benefits.
-Peff
[1] I haven't thought hard enough about it to have a real opinion. My
gut says to go with the streaming, just because we've had to
retrofit streaming in other areas when dealing with blobs, so I
think we'll end up there eventually. So choosing a simpler protocol
like (1) would probably mean eventually implementing a next-version
protocol that does (2), and having to support both.
PS Jakub asked for links, but gmane is down. Here are the relevant threads:
http://public-inbox.org/git/20160720134916.GB19359@xxxxxxxxxxxxxxxxxxxxx
http://public-inbox.org/git/20160722154900.19477-1-larsxschneider%40gmail.com/t/#u
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html