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
