FTP objects

[David Bateman]

One of the things I've had on my Octave ToDo list for a long time and 
something I thought might be easy to do (within the limits of my lack of 
time) is to implement matlab compatible FTP objects.  Yes there is an 
ftp package in octave-forge, but previous discussion excluded porting 
that in the core of Octave as it adds a dependency on ftplib when we 
already have one on curl for the urlread and urlwrite functions. The ftp 
functions are core functions of matlab and so following the logic that 
Octave should have the matlab core functions re-writing them to use 
libcurl is needed to get them into Octave. I have a fairly complete 
implementation of the FTP object type in the attached, though have 
several problems.

The first issue is that Octave currently doesn't have any code in the 
core using OOP and the matlab versions use OOP and so this is needed for 
compatibility. It appears that the new build process doesn't mind a 
scripts/@ftp. Is this the right place for it?

The next problem is that as this type wraps libcurl it has to be 
implemented at least partially in an oct-file. So the oct-files should 
live in the @ftp directory as well. One way should probably be like

@ftp/{ftp.m, display.m, ...}
@ftp/private/__ftp__.oct
@ftp/private/PKG_ADD   ## contains autoloads for the DEFUN_DLD functions 
in __ftp__.oct

though this doesn't work as it appears that "autoload" doesn't work in 
either the private or class directories. In any case such a structure is 
against the separation of OS dependent and independent files, and I'm 
sure the debian packagers at least will complain as I remember well 
discussions about this when the pkg installation paths  were being 
discussed.

Then I suppose a better way to do it is to have two separate @ftp 
directories, one in

${fcnfiledir}/@ftp/{ftp.m,display.m,...}
${octfiledir}/@ftp/private/{__ftp__.oct,PKG_ADD}

Having two separate @ftp directories works, but the autoloads in the 
private directory doesn't yet again. I'd suggest that the autoload issue 
in class and private directories should be fixed before going further 
with this direction.

As the oct-file basically does all of the work an alternative might be 
to have the OOP code in the oct-file itself and get rid of the mfiles. 
The mfiles in this changeset basically pass off all of the work to the 
underlying oct-file. However, I don't see how to do this within the 
build process. Ideas?

What I did in the attached package was to just make the oct-files 
callable anywhere even though they are only useful for the ftp objects 
and added the code to urlwrite.cc so that code might be shared with 
these functions. This avoids needing to fix the private directories with 
oct-files and autoloading, but adds yet more functions starting with __ 
to the global function name space. The advantage for this is that 
nothing special needs to be done for the oct-file installation to put 
them in a different directory than normal. This is what this changeset 
implements

I also have a couple of limitations on the ftp objects. The "dir" 
functions with an output argument returns a structure with the 
filenames, size, modification date and a flag for whether it is a 
directory or not. The ftp "dir" command to the server can't be used to 
fill in this information as the return from the server is dependent on 
the ftp server OS and ftp daemon. I instead used the MDTM command for 
the file modification date, though this appears to give an error for 
directories for all of the servers I tried. I used this fact to flag 
which filename defines a directory, but it also means I have no portable 
means of obtaining the modification date of directories.

The next issue  I have is how do I document an OOP class in the octave 
manual that overloads existing functions like cd, delete, close, mkdir, 
rmdir, etc? I can't use DOCSTRING on the OOP methods so basically all I 
can do is include the non overloaded functions and write a bit of text 
around those the explain the rest. Is there a better way? In any case 
there are a number of duplication errors signaled in the creation of the 
DOCSTRING file, but these don't stop the build itself.

Another question is should I store the password in the FTP object? If I 
want to be able to save the FTP objects to a file and have them work 
when reloaded, then this is needed. However, it can represent a security 
risk, though not much of a one as the password is stored in the octave 
history when the handle was first created. Should I care?

I haven't committed this code but will if others think its ok in its 
current form.

Regards
David

PS: I create the curl_handle class in __ftp__.cc such that it might be 
reused for urlread and urlwrite and reduce the code duplication between 
this existing code and the ftp objects and used this in the urlread and 
urlwrite functions.

--
David Bateman                                address@hidden
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

patch.ftp.bz2
Description: BZip2 compressed data