Hi Sergey, 1. I fail to understand why someone has to extend FtpRequest or session. In case of servlet container no one talks about extending request or session object. Everybody accepts what servlet container provides. So our first target should be to identify the interfaces which will remove the necessity to extend request or session.
2. By session I mean UserSession. Just after connection the UserSession will be null (or invalid) and after login, the request will have a UserSession. UserManager will be responsible to create the session during authentication. In any operating system, file system view depends on the user. Similarly, here also it should be dependent on the UserSession. UserSession invalidation means logout. It does not mean that the connection is lost (INIT command). If you close the connection, the UserSession will be invalidated by the system. 3. I have no problem with it. But I need some more information about it. What should be the structure. When an user reads a file, what are the activities? Thanks, Rana Bhattacharyya --- Sergey Vladimirov <[EMAIL PROTECTED]> wrote: > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
