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 >
