Re: File system implementation

[Sergey Vladimirov <vl...@gmail.com>]

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 <ra...@yahoo.com>:
>
> 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 <vlsergey@gmail.com > 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

Re: File system implementation

[Rana Bhattacharyya <ra...@yahoo.com>]

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 <vl...@gmail.com> 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 <ra...@yahoo.com>:
> >
> > 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 <vlsergey@gmail.com > 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