On 01/20/2014 08:45 PM, Alex Rousskov wrote:
> Hello,
>
> FTP gateway[1] code[2] work well, and we are polishing it for the
> official submission. The biggest change we need to make is to rearrange
> where the new code lives in Squid src directory. In this email, I am
> proposing how to structure that new code, but I start with a little bit
> of a background on the classes involved:
>
> * The current official code has a server-side FTP client that translates
> true HTTP requests (with ftp:// URIs) into FTP commands and FTP
> responses into true HTTP responses. I call this "old FTP client" below.
>
> * The new FTP Gateway code uses a different server-side FTP client that
> translates fake HTTP requests into FTP commands and FTP responses into
> fake HTTP responses. There is now also client-side FTP server code that
> translates true FTP commands into fake HTTP requests and fake HTTP
> responses into true FTP responses.
>
>
> Before the ftp-gw branch changes, most of the FTP code lived in two
> source files (.cc and .h):
>
> src/ftp.* # server-side FTP code (i.e., "FTP client")
> - # non-existent client-side FTP code (i.e., "FTP server")
>
>
> In the current ftp-gw branch, FTP temporary lives in these files:
>
> src/FtpServer.* # code shared by old and new FTP clients
> src/ftp.* # old FTP client
> src/FtpGatewayServer.* # new FTP gw client
> src/client_side.cc # new FTP gw server
>
>
> I propose the following arrangement for the official submission:
>
> src/out/FtpServer.* # code shared by old and new FTP clients
> src/out/FtpToHttp.* # old FTP client
> src/out/FtpGateway.* # new FTP gw client
> src/in/FtpGateway.* # new FTP gw server
> src/ftp/* # FTP code shared by client and server sides
>
>
> I am not happy about the "ToHttp" suffix for the old FTP client class
> but cannot think of a better one. The primary difference between the old
> and new FTP clients is that the former converts FTP responses into true
> HTTP responses, while the latter just wraps FTP responses into "fake"
> HTTP response wrappers (and unwraps them into native FTP responses on
> the client side).
>
>
> One alternative worth considering is accumulating FTP agent (client or
> server) code in their own directories, better separating them from HTTP
> agents (and agents for other protocols on the same side), even though we
> have not done that for HTTP yet:
>
> src/out/ftp/Server.* # code shared by old and new FTP clients
> src/out/ftp/ToHttp.* # old FTP client
> src/out/ftp/Gateway.* # new FTP gw client
> src/in/ftp/Gateway.* # new client-side FTP gw code
> src/ftp/* # FTP code shared by client and server sides
I have not strong opinion on these. The "src/out/ftp/*
looks better but probably it will result to directories with only one or
two source files. The protocol related files (http*, ftp*, gopher*) are
few files.
>
> There has been at least one discussion about related matters, but it did
> not appear to reach consensus on the key questions relevant here.
> Pleases review "[RFC] SourceLayout for client-side and server-side
> components"[3] to avoid rehashing the same set of arguments here.
Just a comment on "in" and "out" directories.
I prefer the "client-side" and "server-side" instead of "in/out" or
"client/server", because it describes better what really is this part of
code.
I remember when I was trying to read squid code, in many cases I was
confused with "client*" or "server*" naming schemes. The client-side
part of squid is a server and the "server-side" is a client.
>
> That old discussion uses CCC and SSS placeholders for client- and
> server-side files. In my proposal above, CCC is "in" and SSS is "out". I
> picked these misleading terms among all other misleading terms already
> discussed simply because they are shorter. If we have to mislead, let's
> at least not waste space!
OK :-)
>
>
> Thank you,
>
> Alex.
> [1] http://wiki.squid-cache.org/Features/FtpGateway
> [2] https://code.launchpad.net/~measurement-factory/squid/ftp-gw
> [3] http://www.squid-cache.org/mail-archive/squid-dev/201303/0054.html
>
Received on Tue Jan 21 2014 - 16:39:05 MST
This archive was generated by hypermail 2.2.0 : Tue Jan 21 2014 - 12:00:32 MST