Re: [RFC/PATCH 0/3] protocol v2

From: Duy Nguyen <pclouds@gmail.com>
Date: Mar 4, 2015, 01:54 UTC
Message-ID: <CACsJy8B_r_0nP9NyKFBnr9bXgwjx8dJkSVkHbZw+Mxin_YpZZw@mail.gmail.com>
In-Reply-To: <xmqqk2yy80mq.fsf@gitster.dls.corp.google.com>

On Wed, Mar 4, 2015 at 12:13 AM, Junio C Hamano <gitster@pobox.com> wrote:

> My recollection is that the consensus from the last time we
> discussed protocol revamping was to list one capability per packet
> so that packet length limit does not matter, but you may want to
> check with the list archive yourself.

I couldn't find that consensus mail, but this one [1] is good enough evidence that we can hit packet length limit in capability line easily.

With an escape hatch to allow maximum packet length up to uint_max, I think we'll be fine for a long time even if we don't send one cap per pkt-line. So I'm trying to see if we really want to go with one cap per pkt-line..

Pros:

 - better memory management, current pkt-line static buffer is probably fine
 - a capability can contain spaces after '='

Cons:

 - some refactoring needed to hide away differences between v1 and v2

Looks like one cap per pkt-line is winning..

[1] http://thread.gmane.org/gmane.comp.version-control.git/237929

-- 
Duy