#30 GSIFTP URL Interpretation

[Steve Crouch]

Gridsam uses a variation on URLs for gsiftp transfers that are relative to a user's home directory, whereas all other methods (sftp etc) use 'normal' URLs that are absolute

For the RAPID project (part of the OMII portlets project) we had to re-implement the apache vfs gsiftp code.This code is more efficient because it uses vfs's caching facilities (GridSAM does not really use this so I suspect that is why they did not implement it that way). But it also fixes the URL problem.

The last patch (gridsam_vfs.patch) changes two import statements so the RAPID code is used instead. It also changes some entries in pom.xml. The RAPID vfs module (which can easily be compiled as a separate jar) is available through Nescforge (http://forge.nesc.ac.uk/ projects/jos) and CVS tab and browse.

This code does require a newer version of commons-vfs however, which causes another problem because apache have decided not to include webdav as standard in the vfs distribution. It is still available through their sandbox though should be compiled into the commons-vfs.jar or in a separate jar.

This changes the external behaviour of the module, potentially breaking existing apps, which is Bad. However, it also fixes a problem (relative URIs), which is Good.

We already have the newer version of commons-vfs integrated and have dealt with the issue over the WebDAV support, so that's not a problem.

Discussion and possible method of specifying gsiftp URIs to get either absolute OR relative paths:

http://blog.distributedmatter.net/? post/2006/12/08/gsiftp-URI-madness

[Reference OMII-UK BugId: #3783]

[Steve Crouch]

Logged In: YES
user_id=1359332
Originator: YES

Jos Koetsier has addressed this issue in the commons-vfs code from the RAPID project on NeSCForge.