Re: [RFC] SourceLayout for client-side and server-side components

On 14/03/2013 1:49 p.m., Alex Rousskov wrote:
> On 03/13/2013 05:10 AM, Amos Jeffries wrote:
>
>
>> 1) we retain the client-side/server-side naming and place the
>> components in a sub-directory off the main protocol directory.
>>
>> src/http/ - HTTP protocol definitions
>> src/http/client - client-side HTTP receiving component
>> src/http/server - client-side HTTP receiving component
>>
>> Pros:
>> * code is all in a clear bundled subdirectory.
>>
>> Cons:
>> * when gatewaying between protocols is not clear where to place the
>> code. We will need to define squid-internal protocol structures
>> separately from any particular client/server-side protocol definition.
>
> In addition to that, this layout is upside down IMO: Protocol is less
> important than the "side" from Squid architecture point of view. Squid
> has only a few "sides". There can be ten or more protocols working on
> each side. And some protocols work only on one side.

This is my proposal #2, with s/receivers/CCC/ s/senders/SSS/

>
> I would recommend starting with this:
>
> src/http - HTTP-specific classes used by both sides
> src/CCC - classes dealing with clients (all protocols)
> src/SSS - classes dealing with servers (all protocols)

Ack. Yes already doing that.

> CCC can be "client", "client_side", "ports", "incoming", "in", "accept",
> or some other misleading term. I cannot think of a good one so I used a
> CCC placeholder. I hope others can come up with something. Perhaps we
> can do what Ubuntu did -- does "client side" sound pretty in some
> popular ancient language? :-)
>
> SSS can be "server", "server_side", "outgoing", "out", "connect", or
> some other misleading term. Client arguments apply here as well.
>
>
> The CCC/SSS naming question is a separate one though. I think we all
> understand what "dealing with proxy clients" means and we have current
> client_side* code as an illustration. Same for the server side.

Starting a new thread for the naming....

>
>
> Needless to say, it would be possible to split protocol-specific code
> inside each side:
>
> src/http - HTTP-specific classes used by both sides
> src/CCC - Mostly protocol-agnostic classes dealing with clients
> src/CCC/http - Very HTTP-specific classes dealing with clients
> ...
>
> but that is secondary and may not be needed.

I don't think we have much HTTP-specific code for dealing with clients
which is not cross-protocol. And we have anyp/ for that. What we have is
HTTP request parsing and HTTP reply parsing code (and the matching
packers). Some HTTP-specific retry and flow control logics.

I saw some issues with the #2 layout, which made me switch to #1 as the
preferred:

  * it requires the client-side parser logics which are _specific_ to
one protocol to be separated from that protocols definitions and shunted
down below CCC/ and likewise for the request packer routines to be
shunted out and under SSS/. If we have any protocols where the
parser/packer pairing are identical (think HTTP/2.0 non-HEADER frames)
this *will* cause problems with eitehr duplicated code or incuding
CCC/*.h into SSS/*.cc and vice versa.
  How often do we need to use FTP parser code in the HTTP parser for
example? SSL handshake logics in the unencrypted HTTP parser?
  I would much rather have that type of code shunted to http/*.h and
http/*.cc files and have http/CCC/*.cc include http/*.h.

* This proposal is for the protocol-specific logics. ie the parsers and
packers rather than the generics ConnStateData, Server.h, Server.cc parts.
  For now the ConnStateData, ClientHttpRequest etc are a little too
tightly bound to HTTP/1.x flow control to be split this way. But the
state and parsing objects they make use of can be shuffled under http/
and their repacements be more generic CCC code for src/CCC/ as you put it.

* We can exclude entire protocol components by omiting a whole library
X/*.la from linking instead of doing the exclusion in multiple places
separately for all the CCC/* files and SSS/* files. This in turn opens
us to the option of dynamically linked/loaded FTP support or CoAP
support or HTTPS support, etc. just by linking the required src/X/*
library as a whole.

Note that all this applies to only the parser/packer code. We will still
need src/X/ and src/CCC/ and src/SSS/ directories whichever one we end
up shuffling the protocol-specific parser/packer code into.

>
>> 2) following the upcoming HTTPbis terminology clarifications as a basis
>> for these components layout. The new specs are emphasising the terms
>> _sender_ and _receiver_ as more precise than client/server. We can use
>> these terms to name our directory structure like so:
> Sender and receiver are single message handling roles. They are _not_
> clients and servers. You have both senders and receivers on the client
> side. You have both senders and receivers on the server side.
>
> I agree that we could split senders and receivers, but the following is
> not how they would have to be split:
>
>> src/receiver/X/= client-side component X.
>>
>> src/sender/X/ = server-side component X.
> It would have to be:
>
> src/CCC/senders/
> src/CCC/receivers/
> src/SSS/senders/
> src/SSS/receivers/

No. Sorry if I wrote this proposal wrong. What it is the same design as
you counter-proposed with:
   CCC = receivers
   SSS = senders

Amos
Received on Fri Mar 15 2013 - 03:56:00 MDT