Hi, Rana First of all, i want to notice, that FTPServer already has Session. But it called FtpRequest. The only problem that it cannot be extended, so we need to introduce SessionFactory, and, may be, rename FtpRequest to Session.
Second. I don't think that moving FTPFileView to Session will be good idea. It should contains some file-system specific connection properties. For example, HTTP-cookies or link to connection to another FTP. We cann't store such fields in FileObject nor it FileSystemManager. Third. About multible FileObject. I want to introduce template for creating new implementations of FileSystems connectors. With this template one can easly said, where should he store file names or where - method to work with files. 2006/1/31, Rana Bhattacharyya <[EMAIL PROTECTED]>: > > Hi Sergey, > > I could not reply as I was working on the > ftpserver status file to use the new template. > > Anyway, at this moment I guess we should first > think about the interface. We are getting many > requests to incorporate the user session and merging > UserManager and FileSystemManager together. I also > think this might be a good idea. So if you change the > implementation now, you have to do it again when we > change the interface. > > About multiple FileObject, my personal opinion is > this is just an implementation issue. Do we really > need to implement an object cache? Because I think the > overhead of multiple FileObject is not a big one as it > internally uses standard java File object. > NativeFileObject is just a wrapper on top of the java > File object. > > The new API structure might look like: > > UserManager > User getUserByName(String login) throws > FtpException; > Collection getAllUserNames() throws > FtpException; > void delete(String login) throws FtpException; > void save(User user) throws FtpException; > boolean doesExist(String login) throws > FtpException; > UserSession authenticate(String user, String > password) throws FtpException; > > UserSession > long getLoginTime(); > String getUserName(); > FileSystemView getFileSystemView(); > void invalidate(); > > Thus we can get rid of FileSystemManager. We can add > the security related methods here too. If we finalize > the API, then we can start thinking about > implementations. > > Please do write your comments. It will help us to come > up with a robust API set. > > Thanks, > Rana Bhattacharyya > > --- Sergey Vladimirov <[EMAIL PROTECTED] > wrote: > > > Hi, all, > > > > I planning to refactor existing file system > > intefaces and implementations. > > Some ideas, which i need to discuss before doing > > this :) > > > > 1. I think, that interfaces should allow every file > > in system to be > > represented only by one FileObject object. Current > > versions of interfaces > > require every user has his own instance of > > FileObject for every File. So, > > maximum count of FileObject is (count of files) x > > (count of users). > > > > More over, this will allow to move all code from > > FileObject to > > FileObjectView, that is better place for code, i > > think. > > > > 2. Improve file security, by extracting specialized > > FileSecurityManager > > interface and increasing count of different checks. > > For example, > > Arp.Sitesystem requires different checks for > > creating directory and > > file, but with > > current interfaces it is not possible. > > > > There will be one abstract class, which redirect > > extended checks to standart > > ones - checkRead, checkWrite checks, like: > > checkWriteDir -> checkWrite > > checkCreateDir -> checkWrite > > checkReadFile -> checkRead > > etc... > > > > -- > > Sergey Vladimirov > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > -- Sergey Vladimirov
