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
