bundle2 suggestions
Michael Edgar
adgar at google.com
Tue Dec 23 03:09:53 UTC 2014
Having followed the bundle2 discussion so far, I think I have some
thoughts at the level of feedback being sought. I hope you find them
helpful :)
Stream parameters are the path for format evolution, so I think the
doc should provide concrete examples of how a stream parameter is
defined and requested. Some great use-cases have been raised already;
let's take a couple and formally define their stream parameters in the
bundle2 spec. Others will implement them, especially if we treat them
as more than a "patches welcome" backdoor.
One idea I particularly liked was capping chunk size - how about we
define "max-chunk-size" and "chunk-size-num-bytes" for the maximum
chunk size and the number of bytes used to encode a chunk's size,
respectively. Now, how will a client with limited buffer space request
a bundle2 with a safe max-chunk-size? If we can include all this in
the bundle2 spec, I think stream parameters can be taken much more
seriously.
I believe drawing a distinction between "mandatory" and "advisory" is
more trouble than it's worth. The general consensus at Google is that
any protocol element that starts out "required" ends up either
optional or cargo culted, and enforced "required" behavior is
especially problematic in formats to be used for both data-at-rest and
data-in-motion. Cryptographic protocols can force a particular
client/server behavior, but for everything else, people *will* break
the spec, often for good reasons you didn't (or couldn't!) foresee.
That's all I really have at the level of the container format - I'm
looking forward to discussions of the new exchange protocols
themselves. Thanks for all your hard work on bundle2, marmoute!
Cheers,
Mike Edgar
More information about the Mercurial-devel
mailing list