I'm still wondering if we should reserve more from the packet length.
We have used length 0000 for pkt-flush. Shawn pointed out that we
still have 0001, 0002 and 0003 but we may use some of them to avoid
abuse of pkt-flush in some cases. Perhaps we could limit packet length
to 0xfff0, so we have 0xfff1-0xffff to assign special meanings in
future, if we have to.
On Sat, Mar 7, 2015 at 6:38 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> +In version 2, when the client initially connects, the server
> +immediately sends its capabilities to the client. Then the client must
> +send the list of server capabilities it wants to use to the server.
> +
> + S: 00XXcapabilities 4\n
> + S: 00XXcap:lang\n
> + S: 00XXcap:thin-pack\n
> + S: 00XXcap:ofs-delta\n
> + S: 00XXagent:agent=git/2:3.4.5+custom-739-gb850f98\n
> +
> + C: 00XXcapabilities 3
> + C: 00XXcap:thin-pack\n
> + C: 00XXcap:ofs-delta\n
> + C: 00XXcap:lang=en\n
> + C: 00XXagent:agent=git/custom_string\n
> +
> +----
> + cap = PKT-LINE("capabilities" SP size LF list)
> + size = *DIGIT
> + capability-list = *(capability) [agent LF]
> + capability = "cap:" keyvaluepair LF
> + agent = keyvaluepair LF
> + keyvaluepair = 1*(LC_ALPHA / DIGIT / "-" / "_" / "=")
If we send one cap per pkt-line, cap can contain spaces. The question
is, should we allow them?
Ending cap lines with LF seems redudant because we already know the line length.
> + LC_ALPHA = %x61-7A
> +----
> +
> +The client MUST ignore any data before the pkt-line starting with "capabilities"
> +for future easy of extension.
> +
> +The server MUST advertise "size" as the decimal number of lines following
> +the "capabilities" line. This includes lines starting "cap:" and "agent:" for now.
> +The client MUST ignore lines which start with an unknown pattern.
I think the common pattern in our protocol is to end these with a
pkt-flush, instead of send the number of items upfront. If we do that
we don't have to specify "cap:" or "agent:" either. All pkt-lines
until pkt-flush at the beginning of v2 are cap lines. And agent is
just another "capability".
--
Duy
--
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