First Analisys on FTPServer

[jl...@br.ibm.com]

Rana,

        I saw the latest source files currently included in the 
apache-incubator CVS repository, and  i was able to identify some 
conflicting points with the solution that we are developing (regarding 
jftp4i). First, i saw that the FTPServer Ftplets are features running 
under a single instance of the server, that means, when the server starts, 
all the Ftplets are defined inside one single instance inside the 
container, so these classes are actually running in a single macro 
application (please correct me if i'm wrong):
        JFTPServer
                        |
                        +--- Container
                        |
                        +--- Ftplets
        In our solution, we are implementing a set of applications that 
can be deployed (inside a *.far file) inside a directory called ftpapps on 
the root directory of the jftp4i server. The engine then maintain these 
*.far resorces as different application instances on the server (very 
similiar to an application server using war files). On each application 
instance, we will have basically a set of files (FTPActions (similiar to 
your Ftplets), FilterEvents, etc.) that are linked to a number of users 
(that are current logged) and to a number of context-roots. When the user 
logs into the server, he automatically see the ctx-roots that he (or she) 
can access, and inside of each ctx-roots, the container have different 
applications responding to all the resources deployed inside the *.far 
file (each far file is an application to the container - not a far pointer 
(kkkk :-)) ).

        The server structure looks something like this:
        root/
          |
          +-- lib/ (necessary library to run the server)
          |
          +-- logs/ (log and trace directory - the transaction container 
uses the trace to control all the steps inside an FTPAction)
          |
          +-- META-INF/ (jftp4i specific configurations - here is where 
you define the applications running on the server)
          |
          +-- ftpapps/ (where the *.far files are deployed - by default, 
the server will have a default.far file to attend all unconfigured client 
requests)

        The structure inside the far file look like this:
        /(any resource and(or)  directory to be supported by the FTP 
application/engine)
        /FTP-INF
              |
              +-- classes/ (FTPActions, Filters, etc..., binary files)
              |
              +-- lib/ (application specific libs)
              |
             ... (application specific descriptors like jftp4i-app.xml)

        An analysis the two solutions, shows that we gonna have a huge 
amount of change and time to merge these projects, and i don´t want to 
start anything without your authorization (evaluation). Of course we also 
don´t want to change anything that you may already spended so much time 
on. So, if you permit me, i want to suggest one thing. Maybe we could 
start the adaptation of the jftp4i (to the JFTPServer) as a FTPServer 
plugin (a subproject of JFTPServer) - some changes may still be necessary 
to adapt the current JFTPServer for supporting the application-server 
plugins.

        This is one possibility, please tell me what you think about it.

        []s,

                João