why does the cmdserver use a 4-byte length field?
Laurens Holst
laurens.nospam at grauw.nl
Mon Jul 4 13:22:52 UTC 2011
Op 01-07-11 15:32, Idan Kamara schreef:
> On Fri, Jul 1, 2011 at 1:13 AM, Jesper Schmidt <schmiidt at gmail.com
> <mailto:schmiidt at gmail.com>> wrote:
> >
> > I mean a 2-byte length field seems to be enough for the input channels.
I think in today's day and age you shouldn't worry about two bytes. Any
performance difference it would make will be basically immeasurable.
What you *should* worry about is that the protocol does not impose
arbitrary limitations that may become a serious limitation in the
future. Y'know, like FAT32's 4GB file size limit (Mercurial's not that
different from a file system... :)).
> > It could also be that 4-byte integers today are more common than 2-byte
> > integers and therefore easier to work with in some newer languages. Is
> > that the motivation for choosing 4 bytes over 2 bytes or is 2 bytes
> > simply not enough? If 2 bytes are not enough then why are 4 bytes then
> > enough?
>
> Theoretically if Mercurial needs to write 4GB in a single call, then
> it won't be enough.
You could use a text-based protocol where the length is a
newline-terminated string of numeric ASCII characters. Then it would be
somewhat more future-proof, support for lengths > 4GB could be added
without requiring a protocol change.
I saw someone even suggesting using a MIME-based protocol? Not such a
bad idea if you ask me :).
~Laurens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20110704/a36bcbf5/attachment.html>
More information about the Mercurial-devel
mailing list