git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Stefan Beller <sbeller@google.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] protocol upload-pack-v2
Date: Sat, 7 Mar 2015 06:55:17 +0700	[thread overview]
Message-ID: <CACsJy8ARDgjBLxYmfyrVcCb5WMnG=w6Ro_j+vVe=Sk6pEfR=Cw@mail.gmail.com> (raw)
In-Reply-To: <1425685087-21633-1-git-send-email-sbeller@google.com>

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@google.com> 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

  parent reply	other threads:[~2015-03-06 23:55 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-24  3:12 [RFC/PATCH 0/3] protocol v2 Stefan Beller
2015-02-24  3:12 ` [PATCH 1/3] Document protocol capabilities extension Stefan Beller
2015-02-24  3:12 ` [PATCH 2/3] receive-pack: add advertisement of different protocol options Stefan Beller
2015-02-24  3:12 ` [PATCH 3/3] receive-pack: enable protocol v2 Stefan Beller
2015-02-24  4:02 ` [RFC/PATCH 0/3] " Duy Nguyen
2015-02-24  5:40   ` Stefan Beller
2015-02-24  6:15   ` Junio C Hamano
2015-02-24 23:37     ` Stefan Beller
2015-02-25 12:44       ` Duy Nguyen
2015-02-25 18:04         ` Junio C Hamano
2015-02-26  7:31           ` Stefan Beller
2015-02-26 10:15             ` Duy Nguyen
2015-02-26 20:08               ` Stefan Beller
     [not found]                 ` <CACsJy8DOS_999ZgW7TqsH-dkrUFpjZf0TFQeFUt9s0bNhHY0Bw@mail.gmail.com>
2015-02-27 22:20                   ` Stefan Beller
2015-02-26 20:13               ` Junio C Hamano
2015-02-27  1:26                 ` Stefan Beller
2015-02-27  2:15                   ` Stefan Beller
2015-02-27 23:05                 ` Junio C Hamano
2015-02-27 23:44                   ` Stefan Beller
2015-02-28  0:33                     ` Junio C Hamano
2015-02-28  0:46                       ` Stefan Beller
2015-02-28  1:01                         ` [RFC/PATCH 0/5] protocol v2 for upload-pack Stefan Beller
2015-02-28  1:01                           ` [RFC/PATCH 1/5] upload-pack: only accept capabilities on the first "want" line Stefan Beller
2015-02-28  1:01                           ` [RFC/PATCH 2/5] upload-pack: support out of band client capability requests Stefan Beller
2015-02-28  7:47                             ` Kyle J. McKay
2015-02-28 11:22                               ` Duy Nguyen
2015-02-28 22:36                                 ` Kyle J. McKay
2015-03-01  0:11                                   ` Duy Nguyen
2015-02-28 11:36                             ` Duy Nguyen
2015-02-28  1:01                           ` [RFC/PATCH 3/5] connect.c: connect to a remote service with some flags Stefan Beller
2015-02-28 11:11                             ` Torsten Bögershausen
2015-03-01  3:22                             ` Junio C Hamano
2015-02-28  1:01                           ` [RFC/PATCH 4/5] daemon.c: accept extra service arguments Stefan Beller
2015-03-01  3:39                             ` Junio C Hamano
2015-02-28  1:01                           ` [RFC/PATCH 5/5] WIP/Document the http protocol change Stefan Beller
2015-02-28 12:26                             ` Duy Nguyen
2015-03-01  9:11                           ` [RFC/PATCH 0/5] protocol v2 for upload-pack Johannes Sixt
2015-03-02  2:58                             ` Junio C Hamano
2015-03-02  3:47                         ` [RFC/PATCH 0/3] protocol v2 Junio C Hamano
2015-03-02  9:21                           ` Duy Nguyen
2015-03-02  9:24                             ` Duy Nguyen
2015-03-03 10:33                             ` Duy Nguyen
2015-03-03 17:13                               ` Junio C Hamano
2015-03-03 19:47                                 ` Junio C Hamano
2015-03-04  1:54                                 ` Duy Nguyen
2015-03-04  4:27                                   ` Shawn Pearce
2015-03-04 12:05                                     ` Duy Nguyen
2015-03-04 19:10                                       ` Shawn Pearce
2015-03-05  1:03                                         ` Stefan Beller
2015-03-05 16:03                                           ` Stefan Beller
2015-03-24 17:42                                 ` Stefan Beller
2015-03-24 18:00                                   ` Junio C Hamano
2015-03-06 23:38                             ` [PATCH] protocol upload-pack-v2 Stefan Beller
2015-03-06 23:40                               ` Stefan Beller
2015-03-06 23:55                               ` Duy Nguyen [this message]
2015-03-07  0:00                               ` Duy Nguyen
2015-03-07  0:28                               ` Junio C Hamano
2015-03-07  4:28                                 ` Stefan Beller
2015-03-07  5:21                                   ` Duy Nguyen
2015-03-08 20:36                                   ` Junio C Hamano
2015-03-31 19:58                                     ` Junio C Hamano
2015-04-02 12:37                                       ` Duy Nguyen
2015-04-02 14:45                                         ` Junio C Hamano
2015-04-02 22:18                                       ` Martin Fick
2015-04-02 22:58                                         ` Junio C Hamano
2015-04-02 23:00                                         ` Stefan Beller
2015-04-02 23:14                                           ` Stefan Beller
2015-03-10  1:38                               ` Duy Nguyen
2015-03-10 19:36                                 ` Kyle J. McKay
2015-02-28  0:07                   ` [RFC/PATCH 0/3] protocol v2 Duy Nguyen
2015-02-28  0:26                     ` Junio C Hamano
2015-03-01  8:41     ` Junio C Hamano
2015-03-01 11:32       ` Duy Nguyen
2015-03-01 19:56         ` Stefan Beller
2015-03-02  1:05           ` David Lang
2015-03-01 23:06         ` Junio C Hamano
2015-03-02  1:09           ` David Lang
2015-03-02  3:10             ` Junio C Hamano
2015-03-01 23:06       ` Philip Oakley
2015-03-02  9:32         ` Duy Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACsJy8ARDgjBLxYmfyrVcCb5WMnG=w6Ro_j+vVe=Sk6pEfR=Cw@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).