[ http://issues.apache.org/jira/browse/FTPSERVER-19?page=comments#action_12331251 ]
Rana Bhattacharyya commented on FTPSERVER-19: --------------------------------------------- I think your logic is right. This is what I understand. 1. FileSystemView is the user file system view so it can have canDelete() and canRead() methods ..... this is fine. 2. FileSystemView can have user object to indicate whose file system view it is representing. 3. In that case, caching will be at the FileSystemView level (not at FileObject level). Logically this is also fine. NativeFileSystemView represents the underlying OS file system view - no more no less. Caching is a specialized function. So if necessary we can add another FileSystemManager implementation which will support caching. But it may not be appropriate to add this in NativeFileSystem classes. So the action items: 1. canDelete(), canRead() and canWrite() will be moved to FileSystemView from FileObject. > Question about FileObject - should it depends on User? > ------------------------------------------------------ > > Key: FTPSERVER-19 > URL: http://issues.apache.org/jira/browse/FTPSERVER-19 > Project: FtpServer > Type: Wish > Reporter: Sergey Vladimirov > > Does FileObject need to depend from User, or different users can share same > FileObject? > Second variant is good choice for caching and reusing file objects - we can > put all files to cache (where key is they full name), and user-depended code > will be only in FileSystemView. > Now first variant is implemented. > If no marks or suggestions until Tuesday evening (MSK), I will do it - it the > simpliest way to implement files security chinking in my system (Arp.Site). > (Please, report me, if you found a bug in my English :) Patches are welcome ) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
