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

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 <squid3_at_treenet.co.nz> 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