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

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.

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)

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.

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.

> 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/

or, if my arguments that "side" is a higher-level concept than protocol
or message handling role are overruled, then:

    src/senders/CCC/
    src/senders/SSS/
    src/receivers/CCC/
    src/receivers/SSS/

HTH,

Alex.
Received on Thu Mar 14 2013 - 00:49:04 MDT