2010/6/23 Frank van der Kleij <[email protected]>:
>
> Thanks for your reply, I shouldn't have written that hasty message.
> Part of what I wrote is client side code (VFS shell) but I also did the 
> integration for the server part, both for SSHD (Shell, Scp and Sftp) and for 
> FtpServer. For Scp and Sftp this is messy because I had to copy most of the 
> code because of the lacking file abstraction layer, see for example 
> http://vfs-utils.svn.sourceforge.net/viewvc/vfs-utils/trunk/shell/sshd/src/main/java/org/vfsutils/shell/sshd/VfsSftpSubsystem.java?view=markup.
>  For FtpServer this is much better.
> So if you would like to use Commons VFS as a file abstraction layer you have 
> an example. Whether you would want to use Commons VFS is a good question. 
> Though I like its underlying idea a lot, it is a bit complicated, especially 
> compared to the abstraction layer of the FtpServer - for a part this is 
> normal because it has to serve many more uses.


Actually I took a look at Frank's implementation a while ago and I
think it's pretty cool... it's a shame that commons-vfs isn't
receiving more contributions!

Another option you may want to evaluate is delegating the Database
access to a FUSE db-based fileystem:
http://sourceforge.net/apps/mediawiki/fuse/index.php?title=DatabaseFileSystems

FUSE is a project that allows programmers to implement several
filesystems in a user space program in Linux (and I guess other UNIX
flavors), and there are tons of these implementations!   So, the same
way you can mount a "ext3 filesystem" you can mount a e.g., 'mysqldb
filesystem' and thus your program will use a database as the storage
point with no changes in the File access code.




> I didn't know Cotta - thanks for the tip - but it would seem a bit strange to 
> me for an Apache project to use Cotta instead of Commons VFS.
> If it were only pointers for inspiration then I would focus more on the 
> FtpServer abstraction layer, since it is the closest to what you'd want.The 
> main difference I see is the focus on RandomAccess for Sftp.
> I hope this is more useful then my last mail,
> Frank
>
>> Date: Tue, 22 Jun 2010 13:20:24 +0200
>> Subject: Re: sshd/sftp backed by db
>> From: [email protected]
>> To: [email protected]
>>
>> My understanding is that what you wrote is slightly different from
>> what is being discussed.  We're discussing how the Sftp subsystem can
>> be used on top of a virtual file system, with the ideas to reuse what
>> FtpServer provides or backed by a DB for example.  The project you
>> created, while very valuable, seems targetted at the client side,
>> which is not what we were looking for here.
>>
>> On Tue, Jun 22, 2010 at 11:44, Frank van der Kleij <[email protected]> wrote:
>> >
>> >
>> > For Apache Commons VFS I already did the work, see 
>> > http://vfs-utils.sourceforge.net/shell/sshd.html
>> >
>> > Cheers,
>> > Frank
>> >
>> >
>> >> Date: Mon, 21 Jun 2010 09:52:16 +0200
>> >> Subject: Re: sshd/sftp backed by db
>> >> From: [email protected]
>> >> To: [email protected]
>> >>
>> >> 2010/6/14 Chuck Johnstone <[email protected]>:
>> >> > That sounds quite reasonable.  I'll take a look at using FtpFile.
>> >>
>> >> Other projects you might find worth looking at are Apache Commons VFS
>> >> and COTTA file system. These two have a File API which seems
>> >> nicer/more extensible than java.io.File
>> >>
>> >>
>> >>
>> >> > On 10-06-14 03:36 AM, Guillaume Nodet wrote:
>> >> >>
>> >> >> Thinking a bit more about this, I think the following would make sense:
>> >> >>   * copy FtpFile and NativeFtpFile from FtpServer into the sshd 
>> >> >> subsystem
>> >> >> package
>> >> >>   * copy the SftpSubsystem to AbstractSftpSubsystem and rework it to 
>> >> >> use a
>> >> >> FtpFile root
>> >> >>   * rework SftpSubsystem to inherit AbstractSftpSubsystem and just 
>> >> >> provide
>> >> >> a
>> >> >> NativeFtpFile file system root
>> >> >>
>> >> >> For the long term solution, I think it would make more sense to do the
>> >> >> work
>> >> >> in FtpServer and use SSH as an addition transport layer, thus reusing 
>> >> >> user
>> >> >> management, file system users configuration and all ...  It should be 
>> >> >> then
>> >> >> really simple to implement an org.apache.sshd.server.sftp.FtpFile on 
>> >> >> top
>> >> >> of
>> >> >> the existing ftpserver FtpFile and provide a user authentication 
>> >> >> mechanism
>> >> >> delegating to the ftpserver auth mechanism.
>> >> >>
>> >> >> On Mon, Jun 14, 2010 at 11:27, Guillaume Nodet<[email protected]>  
>> >> >> wrote:
>> >> >>
>> >> >>
>> >> >>>
>> >> >>> On Thu, Jun 10, 2010 at 20:19, Chuck Johnstone<
>> >> >>> [email protected]>  wrote:
>> >> >>>
>> >> >>>
>> >> >>>>
>> >> >>>> Hi,
>> >> >>>>
>> >> >>>> As per the previous email I'm going to experimentally rework
>> >> >>>> SftpSubsystem
>> >> >>>> to use a db backend.
>> >> >>>>
>> >> >>>> My current approach is to copy SftpSubsystem and abstract out the 
>> >> >>>> file
>> >> >>>> access.  The new class is called AbstractSftpSubsystem.
>> >> >>>>
>> >> >>>> Right now I've created an interface that mimics all the pertinent 
>> >> >>>> bits
>> >> >>>> of
>> >> >>>> java.io.File as used in SftpSubsystem.
>> >> >>>>
>> >> >>>> The interface currently looks like this:
>> >> >>>>
>> >> >>>>    public static interface SftpFile { // from java.io.File
>> >> >>>>        boolean exists();
>> >> >>>>        boolean createNewFile();
>> >> >>>>        SftpFile getParentFile(); // based on File.getParentFile()
>> >> >>>>        String getPath();
>> >> >>>>        long length();
>> >> >>>>        boolean canRead();
>> >> >>>>        boolean canWrite();
>> >> >>>>        boolean isFile();
>> >> >>>>        boolean isDirectory();
>> >> >>>>        long lastModified();
>> >> >>>>        SftpFile[] listFiles();
>> >> >>>>        String getName();
>> >> >>>>        boolean delete();
>> >> >>>>        boolean mkdir();
>> >> >>>>        boolean renameTo(SftpFile dest);
>> >> >>>>        SftpFile getAbsoluteFile();
>> >> >>>>    }
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>> Yeah, looks good.  Though, we'd need to be able to read / write to 
>> >> >>> those
>> >> >>> files, which isn't possible in this interface.
>> >> >>> I really wonder if a simplier approach would be to just copy the 
>> >> >>> FtpFile
>> >> >>> interface [1] into the subsystem package.  At least, we'd know that 
>> >> >>> we'll
>> >> >>> be
>> >> >>> able to bridge with FtpServer quite easily.
>> >> >>>
>> >> >>> [1]
>> >> >>>
>> >> >>> http://svn.apache.org/viewvc/mina/ftpserver/trunk/ftplet-api/src/main/java/org/apache/ftpserver/ftplet/FtpFile.java?view=markup
>> >> >>>
>> >> >>>
>> >> >>>>
>> >> >>>> I believe this is in line with the discussion so far.  If there is a
>> >> >>>> better way let me know.  I'll submit patches if you think this 
>> >> >>>> approach
>> >> >>>> is
>> >> >>>> useful.
>> >> >>>>
>> >> >>>> Cool ! Patches is the way to go ...
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>>>
>> >> >>>> The good news is that my company is funding the development time.  
>> >> >>>> The
>> >> >>>> above approach is our short term solution to this problem but we're 
>> >> >>>> also
>> >> >>>> interested in a longer term solution.  Mention was made of moving 
>> >> >>>> this
>> >> >>>> into
>> >> >>>> apache ftpServer.  We intend to help with that too.  I've used 
>> >> >>>> ftpServer
>> >> >>>> to
>> >> >>>> implement a backend FTPS solution so I'm a bit familiar with the 
>> >> >>>> system
>> >> >>>> but
>> >> >>>> I'm not familiar with the details of SFTP.  I'm assuming that SFTP 
>> >> >>>> code
>> >> >>>> from
>> >> >>>> SftpSubsystem could be ported into Mina ftpServer structures.
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>> Well, I'm not very familiar with the FtpServer project.  I wonder if 
>> >> >>> it
>> >> >>> would be easier / cleaner to integrate SSHD into FtpServer project as 
>> >> >>> an
>> >> >>> additional transport, or integrate FtpServer into SSHD as a new 
>> >> >>> backend
>> >> >>> for
>> >> >>> SFTP subsystem.  Maybe other FtpServer people can jump in and throw 
>> >> >>> some
>> >> >>> ideas here.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>>
>> >> >>>> I'll be focused on the short term solution over the next few weeks 
>> >> >>>> but
>> >> >>>> after that I can move onto the longer term solution.
>> >> >>>>  Discussion/guidance in
>> >> >>>> this task will be greatly appreciated.
>> >> >>>>
>> >> >>>> Chuck Johnstone
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Cheers,
>> >> >>> Guillaume Nodet
>> >> >>> ------------------------
>> >> >>> Blog: http://gnodet.blogspot.com/
>> >> >>> ------------------------
>> >> >>> Open Source SOA
>> >> >>> http://fusesource.com
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >
>> > _________________________________________________________________
>> > New Windows 7: Simplify what you do everyday. Find the right PC for you.
>> > http://windows.microsoft.com/shop
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
> _________________________________________________________________
> New Windows 7: Simplify what you do everyday. Find the right PC for you.
> http://windows.microsoft.com/shop

Reply via email to