Re: [PATCH v2 03/11] serve: add "receive" method for v2 capabilities table

From: Jeff King <peff@peff.net>
Date: Sep 15, 2021, 16:57 UTC
Message-ID: <YUIl8hhzi3aE1FA/@coredump.intra.peff.net>
In-Reply-To: <xmqqpmt9yeo7.fsf@gitster.g>

On Wed, Sep 15, 2021 at 09:41:28AM -0700, Junio C Hamano wrote:

Show 15 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > +	/*
> > +	 * Function called when a client requests the capability as a
> > +	 * non-command. This may be NULL if the capability does nothing.
> > +	 *
> > +	 * For a capability of the form "foo=bar", the value string points to
> > +	 * the content after the "=" (i.e., "bar"). For simple capabilities
> > +	 * (just "foo"), it is NULL.
> > +	 */
> > +	void (*receive)(struct repository *r, const char *value);
> 
> What does "as a non-command" mean?  To put it another way, when a
> client requests the capability as a command, what does the receive
> method do differently?

For each entry in this capability table, clients can say:

  command=foo

or just:

foo

The latter is a non-command. The "receive" function is not called at all if it is a "command". I think this is a bit more clear when read together with the existing function just above (which you can't see in the diff context):

        /*
         * Function called when a client requests the capability as a command.
         * Will be provided a struct packet_reader 'request' which it should
         * use to read the command specific part of the request.  Every command
         * MUST read until a flush packet is seen before sending a response.
         *
         * This field should be NULL for capabilities which are not commands.
         */
        int (*command)(struct repository *r, struct packet_reader *request);

I guess these could define "as a command", but I think it's pretty clear in the context.

Show 7 quoted lines

> >  static int parse_command(const char *key, struct protocol_capability **command)
> > @@ -262,7 +277,7 @@ static int process_request(void)
> >  		case PACKET_READ_NORMAL:
> >  			/* collect request; a sequence of keys and values */
> 
> The comment tentatively gets slightly stale here, but that will be
> corrected at the end, so it would be fine ;-)

Hmm. I think it is not stale here, as we are still collecting the "keys" strvec. But it _does_ get stale by the end, when we stop doing so.

I'm preparing a re-roll for the test issues Eric noted, so I'll drop that comment in the appropriate patch.

-Peff