Re: [RFC/WIP PATCH 00/11] Protocol version 2, again!
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Jun 2, 2015, 10:10 UTC
- Message-ID
- <CACsJy8CGW-Kaq6hkox03w5bQS2=tVNMzShKUBgC6wKX9dkMQGw@mail.gmail.com>
- In-Reply-To
- <CAGZ79kZxFnkneixquUijd2yfKBh6+XnYiYzCh8L9Mkourh64Fw@mail.gmail.com>
On Tue, Jun 2, 2015 at 12:49 AM, Stefan Beller <sbeller@google.com> wrote:
Show 12 quoted lines
> However the client side with builtin/fetch, builtin/fetch-pack, fetch-pack
> is a bit of a mystery to me, as I cannot fully grasp the difference between
> * connect.{h,c}
> * remote.{h.c}
> * transport.{h.c}
> there. All of it seems to be doing network related stuff, but I have trouble
> getting the big picture. I am assuming all of these 3 are rather a low level,
> used like a library, though there must be even more hierarchy in there,
> connect is most low level judging from the header file and used by
> the other two.
> transport.h seems to provide the most toplevel library stuff as it includes
> remote.h in its header?I think transport.c is there to support non-native protocols (and later on, smart http). So yeah it's basically the API for fetches and pushes. git-log over those files may reveal their purposes, especially the few first versions of them.
Show 31 quoted lines
> The problem I am currently trying to tackle, is passing the options through all
> the layers early on. so in a few places we have code like
>
> switch (version) {
> case 2: /* first talk about capabilities, then get the heads */
> get_remote_capabilities(data->fd[0], NULL, 0);
> select_capabilities();
> request_capabilities(data->fd[1]);
> /* fall through */
> case 1:
> get_remote_heads(data->fd[0], NULL, 0, &refs,
> for_push ? REF_NORMAL : 0,
> &data->extra_have,
> &data->shallow);
> break;
> default:
> die("BUG: Transport version %d not supported", version);
> break;
> }
>
> and the issue I am concerned about is the select_capabilities as well as
> the request_capabilities function here. The select_capabilities functionality
> is currently residing in the high level parts of the code as it both depends on
> the advertised server capabilities and on the user input (--use-frotz or config
> options), so the capability selection is done in fetchpack.c
>
> So there are 2 routes to go: Either we leave the select_capabilities in the
> upper layers (near the actual high level command, fetch, fetchpack) or we put
> it into the transport layer and just passing in a struct what the user desires.
> And when the users desire doesn't meet the server capabilities we die deep down
> in the transport layer.I read the latest re-roll and I think the placement makes sense. You can't put protocol specific at transport level because "pack protocol" is just one of the supported protocols. There is smart-http (which shares a bunch of code, but from transport perspective is a separate protocol), and then user-defined protocols that know nothing about this v2.
-- Duy