Re: [RFC] FTP gw source layout

On 01/21/2014 03:54 PM, Amos Jeffries wrote:

> [ On a side note shall we make a proper effort to fix that confusion by
> deprecating our use of the terms and call bits client or server by
> functionality? it would be as easy to describe these area-based parts as
> client-facing or server-facing areas of Squid. We already talk of ICAP
> as a "client" despite being both "client-side" and "server-side".
>
> Your updated proposal below would seem to be a good move in that
> direction. If we can agree to stop saying/writing those terms and start
> replacing documentation we can probably make naming decisions a lot less
> confusing in the near future. ]

If the proposed Native FTP naming scheme is accepted, we will indeed
migrate away from the end-agent proximity model towards a protocol
role-based model and, personally, I will do my best to avoid
"client-side" and "server-side" terminology.

>> Keep in mind that "relay" (with various filtering capabilities offered
>> by Squid) is essentially a "proxy". This project was called Native FTP
>> Proxy.
>
> Essentially is the word. With one fine distinction: Relay is transparent
> in the protocol (essentially 'dumb'), Proxy may adjust and make changes
> to the message semantics as they go through.

In our case, Squid adjusts native FTP message semantics (e.g., Squid may
convert an active data transfer request into a passive one or strip some
FEAT response items) and adaptation services may do so as well (e.g.,
block or even adjust certain FTP downloads).

>> [FWIW, the term "FTP Gateway" was suggested by Henrik during initial RFC
>> review. Henrik thought that using HTTP semantics internally means we are
>> a "gateway". I changed the project name in order to avoid having an
>> argument. Technically, it is not really clear whether we are using HTTP
>> semantics internally or not. We are using HTTP structures, but semantics
>> is a very gray area IMO.]
>
> [ This last point is one reason I really want to make the move from a
> structures based internal representation to passing around frames. That
> was we can simply call each of these FTP messages a frame (might even
> stay in FTP native format) and be done with it. ]

I am happy to discuss what you mean by frames that are not
structure-based, and what we should use them for, but let's do that
elsewhere. I am pretty sure that the primary problems with that
migration are not in the primitive ways Native FTP code is using [so
called] HttpMsg objects.

>> "Gadgets" names a collection of handy little things. It does not work at
>> all for a base FTP client class IMO.
>
> Okay. Anything better? or are we stuck with FtpStateData for a while
> longer?

If the proposal below is implemented, the base FTP client class will be
just that: Ftp::Client.

>> 1) The new Feature is going to be called "Native FTP Proxy". The old
>> "FTP Gateway" code name is dropped.
>>
>
> Ok.
>
>> 2) We are going to use the following layout for the FTP code:
>>
>> src/servers/FtpServer.* # new FTP server, relaying FTP
>> src/clients/FtpClient.* # code shared by old and new FTP clients
>> src/clients/FtpGateway.* # old FTP client, translating back to HTTP
>> src/clients/FtpNative.* # new FTP client, relaying FTP
>> src/ftp/* # FTP stuff shared by clients and servers
>>
>
> Ok.
>
>> 3) The remaining non-FTP code will be eventually moved into appropriate
>> files and directories inside src/clients/ and src/servers/ structure,
>> and the corresponding files/classes will be renamed at that time. Doing
>> so is outside the FTP Gateway project scope and is likely to happen one
>> class (or one group of files) at a time.
>
> Sure.
>
> +1 on this proposal.

Great! I will wait a few days before implementing #1 and #2 to give
everybody else a better chance to voice their opinion, including objections.

Thank you,

Alex.
Received on Wed Jan 22 2014 - 00:36:55 MST