One of the ssues we have oustanding in the SourceLayout project is how
exactly to organize the client-side and server-side components. We did
agree that they should be kept separate. However no ideas were discussed
about particular naming schemes or code layouts. This has been hampering
efforts to restructure the code in those two main areas.
I'm partial to proposal #1:
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.
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:
Each client-side X_port component having its own sub-directory under the
receiver/ one containing the code for receiving the target protocol and
translating/parsing into our internal HTTP structures. With each
server-side component having a subdirectory under the sender/ directory
containing the code for translating/packing our internal HTTP structures
into the target protocol and sending it.
src/receiver/X/= client-side component X.
src/sender/X/ = server-side component X.
These directories should not include the code for defining any of the
target protocol definitions or structures, which are placed at teh upper
level under src/X/ . Just the data flow logics required by client-side
and server-side operations.
Pros:
* allows us to import new protocols or client/server -side components
separately and enforces a distinction between the three types of component.
Cons:
* the protocol code is split into three places, which might not be
such a great idea for ease of development.
Amos
