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.
