On 03/15/2013 04:36 PM, Amos Jeffries wrote:
> Okay. We seem to be in agreement about the parser/packer code. The rst I
> guess we can wait a bit and see if it beccomes clearer once that code is
> shuffled out.
Which in itself will be challenging because HttpRequest, for example,
has a lot of stuff that does not belong to src/http/ (and a lot of stuff
that does belong there, naturally). If you work on this, I recommend
starting with simpler HTTP pieces though.
>>>> 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)
>> Perhaps it would be useful to clarify the above by saying that:
>>
>> a) There are other Squid sides not shown above (e.g. adaptation).
>> We just use CCC and SSS as two primary examples.
>
> This is a good example why splitting it by side at the upper level
> rather than by protocol is _worse_. I'm after consistency here - if you
> are looking for the parser from ftp-client code or http-client or
> gopher-client or icap-client you should expect to be able to look in a
> similar place.
I do not see the problem you are referring to. If I want an FTP message
parser, I will look in src/ftp/. If I want code that establishes
connection to the FTP server, I will look in src/SSS.
Can we put the FTP server connection management code in src/ftp/? Yes,
we can. The only problem with that is that no everybody that needs FTP
module needs to establish a connection with an FTP server. If you keep
that code in src/SSS/ftp*, you will not expose SSS-details to other
Squid sides that do not need to know them.
>> b) There are other protocols not shown above (e.g. FTP).
>> We just use HTTP as a primary example.
>
> Another example of why splitting by 'side' is bad. FTP protocol stuff
> does not get used in adapted/, nor does gopher/ or icp/ or htcp/. But
> icap/ does get used in both client-side/ and server-side/.
I do not see what is bad about one protocol not being used by some other
module or used by multiple modules. Seems like a normal situation to me.
I see no inconsistency here: Every module provides what it was defined
to provide; every module hides what no other module needs; modules use
what they need from other modules. The directories we are discussing
here are such software modules, essentially.
>> c) Any HTTP code used by more than one side belongs to src/http/
>> d) Any code used by more than one side does not belong to src/side/
>
> Okay. Agreed on that.
Glad we are making progress.
> When you look at it this way ICAP protocol parse/pack belongs under an
> src/icap/ as much as src/http/ deserves its own.
Agreed. ICAP primitives can be moved from src/adaptation/icap/ to
src/icap/ when something other than the adaptation side needs them (not
enough will be gained to move them prior to that IMO).
> Because it is used by adaptation at both REQMOD and RESPMOD "sides".
No, all ICAP methods belong to the same "adaptation" side of Squid. Do
not forget that it is possible to do REQMOD (and RESPMOD) from both CCC
and SSS sides, we just do not support that yet. The adaptation side is
defined as "code dealing with message adaptation services" and includes
ICAP, eCAP, and even the built-in http_request_add "service".
HTH,
Alex.
Received on Fri Mar 15 2013 - 23:36:32 MDT
This archive was generated by hypermail 2.2.0 : Sat Mar 16 2013 - 12:00:07 MDT