Re: [RFC] FTP gw source layout

On 2014-01-21 07:45, 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).

These are all backwards conceptually.

* Gateway - translating in/ transport to out/ transport. Seems to
describe what the old client code does pretty closely both against the
dictionary and RFC terminology definitions for gateway.

* Relay - passing in/ transport to same out/ transport. Seems to
describe what the new code does if we ignore the messy internal
representation mapping.

* out/FtpServer contains FTP clients. Lets not do this. Yes it does kind
of make sense if one has a lot of knowledge about Squid. But for most it
will be amazingly confusing. The "gadgets" terminology we started using
fits here, so I propose FtpGadgets.* to help reduce confusion.

>
> 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

For now I think we leave this, it can be done later if we end up with
similar models for other protocols. (FYI: I kind of dislike the whole
fake-HTTP request mapping, but lacking a better alternative am not
arguing against it at this point).

> src/ftp/* # FTP code shared by client and server sides
>

This bit was already agreed on in the earlier thread.

NP: The only reason the in/ out/ bits are not started yet for HTTP is
that I have been concentrating on shuffling out these shared bits to see
what is left specifically for client/server-side and whether that gives
any hint as to better directory names for those parts.

>
> 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.
>
> 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!
>

Agreed. I am still finding all the names we can think of feel a bit
contrived. At least in/ and out/ are shorter and fit by way of being
more general than our somewhat squid-specific terminology. We can always
rename later if something better is thought up.

Amos

>
> 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 Mon Jan 20 2014 - 22:30:32 MST