Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <40A4AD3C.2070702@apache.org>
Date: Fri, 14 May 2004 13:27:56 +0200
From: Mario Ivankovits <imario@apache.org>
User-Agent: Thunderbird 0.6 (Windows/20040502)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [VFS]: Integration - too early?
References: <7395B46C07F8D51182AE000629570CC4B2E564@ike.local.anstat.com.au>
In-Reply-To: <7395B46C07F8D51182AE000629570CC4B2E564@ike.local.anstat.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Paul Smith wrote:

>The certificate that I would signing with would display my psmith@apache.org
>email inside it.  Now obviously I wouldn't have written a single line of the
>commons code, and just wanted to make sure no-one can foresee a problem with
>that.  We'd obviously give appropriate credit within Chainsaw to the
>commons-dev team.
>  
>
As far as i understand the community idea - there should be no problem 
with this. At least not for me.

>* Is VFS still in a state of flux?
>  
>
Well - quite some time not much happened in VFS - i picked it up now and 
try to implement what ever comes in my head.
However - i try not to change the current api too much. Maybe to one or 
other method will be added.
I will be happy to work together with the log4j team to make the 
integration into chainsaw reality.

>* Does VFS have a feature to dynamically detect which file systems are
>'available'? 
>  
>
Yes - one of the methods to get a filesystemmanager is by using the 
StandardFilesytemManager - it uses a providers.xml where the possible 
filesystem-types are defined and also the needet classes.
If the dependency check failes the provider is not available.

e.g.
    <provider 
class-name="org.apache.commons.vfs.provider.http.HttpFileProvider">
        <scheme name="http"/>
        <if-available 
class-name="org.apache.commons.httpclient.HttpClient"/>
    </provider>

>* This might be File system specific, but does anyone know whether, for a
>given FileObject, one might be able to read a portion of the, say, text
>file, and only grab the first X lines of it for a preview?
>
Currently a simple InputStream is provided. As always you could wrap it 
e.g. into an BufferedReader and use readLine().
So the answer is YES.
However - we have to check how e.g ftp react if you close the stream in 
the mid of the transfer.

One of the things i would implement in the future is to provide access 
to the file by some sort of RandomAccessFile - for sure - for the 
filesystems where it is possible.
But it should be possible to use the restart-capability of some 
ftp-server to simulate this behaviour.

>* I don't know much about SFTP, but does this support the ability to
>'browse' a remote directory?
>
YES.
This brings me back to the previous question.
Currently the SFTP provider reads the complete file into memory - i have 
to check if this is still needet.
But even if i change this - it is transparent to the above outlined 
solution.

>I assume if one has setup certificate-based authentication for a local ssh with a remote
>location, the password wouldn't even be needed here.  Would that work? (ie
>the usual ~/.ssh/authorized_keys file etc)
>  
>
This should work too - but i will test this again.
Another problem here is the fact, that it is not easily possible to find 
the location of the key-files on the client side - the current code 
tries to figure out some places:
1) check "vfs.ftp.sshdir" system-property
2) check "user.home"/.ssh
3) check c:\\cygwin\\home\\"user.name"\\.ssh

I DEFINITELY WILL CHANGE THIS.
I know from some old communication between the original authors and me, 
that they never ever wanted to use system-properties - all has to be 
configured by the application.
In the past it was a problem to send some configuration to the 
filessystem - now it is not.

>That's all I can think of for now.  If anyone is interested in trying out
>the current stable version of Chainsaw
>
I currently use the cvs-head version of chainsaw2 (and a patched 
commons-logging). The chainsaw stuff was motivation enough to change our 
complete custom loggin solution to commons-logging with log4j as backend.
Keep on going !!!

-- Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org