Hi, Option 1) seems easier to grasp and maintain to me. At most we can mix the two, by going src/http/ src/http/sender/ src/http/receiver/
instead of client/ and server/. But generally speaking, a protocol is IMO a more closely-related family of concepts than being client or server in a transaction On Wed, Mar 13, 2013 at 12:10 PM, Amos Jeffries <[email protected]> wrote: > 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 -- /kinkie
