Re: FTP objects

[David Bateman]

John W. Eaton wrote:
> | 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?
>
> That seems OK to me.
>   
It seems that scripts/ is on the path but scripts/@ftp isn't so things 
as they stand seem fine.

> | 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}
>
> If we do this, then maybe we should be doing some magic in the
> load-path searching code so that the correspondence between the
> ${fcnfiledir}/@ftp and ${octfiledir}/@ftp is handled automatically?
> Maybe there should be a directive that could appear in the
> ${fcnfiledir}/@ftp/PKG_ADD file that tells Octave to merge the
> contents of the ${octfiledir}/@ftp with ${fcnfiledir}/@ftp?  Or should
> both directories should appear in the load-path?
>   
Do they need to correspond? Can't e just have two separate directories? 
I tried a simple case with half the code in one @ftp directory and half 
in another and there seemed to have no issues...

> | 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.
>
> How should it be fixed?  Should we be searching for PKG_ADD files in
> private directories?  I guess that currently we are only looking for
> PKG_ADD files in directories that actually appear in the load-path and
> since private directories don't appear explicitly, we don't search for
> PKG_ADD files there.
>   
Even the @ftp directory itself isn't on the path and so the PKG_ADD 
files there won't be found either if they are in @ftp. I attach some 
test code that I used to look at this issue. Even if the PKG_ADD is in 
the parent of the class directory the oct-file is not found by the 
autoload command. So its not just that the executing the PKG_ADD files 
in class and private directories, but allowing the autoload command to 
find the functions in these directories.
> | 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?
>
> Does it work to create
>
>   ${octfiledir}/@ftp/{__ftp__.oct,PKG_ADD}
>
> and have the PKG_ADD file provide the autoloads for the individual
> function names?  Then we would still be relying on the user to
> recognize that __ftp__ is an internal function instead of enforcing it
> with the private directory structure.
>   
No as the PKG_ADD file isn't yet found in this case.

> Or are you asking how should the ${octfiledir}/@ftp subdirectory be
> created within the current build scheme?  I could help with that if we
> decide that is needed.
>   
This was more the question I was asking.... Do we want to allow classes 
in oct-files? If so a change to the build process to allow installation 
in ${octfiledir}/@directory/ will be needed. Even if we only want to 
allow oct-files in private directories of classes we'd still need 
something similar.

> | 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 think this is OK for now, but I would like to move the __x__
> functions to private directories, so we need to discuss and decide how
> best to handle private .oct files and also whether the .oct files
> should be somehow grouped together with corresponding .m files (i.e.,
> should we implement some kind of merged directories for the load-path
> searching code so that we can keep architecture dependent and
> independent files separate but have the load-path searching code see
> certain directories as belonging together?).
>   
It  the existing code isn't what we want then in the case of the FTP 
objects its probably better with a little rewriting to have the oct-file 
itself support the class as the m-files essentially do nothing and not 
need the private directory at all.

I don't believe the merge is necessary at the level of the path itself 
as long as a private function or class function in 
${fcnfiledir}/@directory can call a private function in 
${octfiledir}/@directory and visa-versa. I haven't check if this is 
possible with the current code however.

> | 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.
>
> How about the following change?
>
>   http://hg.savannah.gnu.org/hgweb/octave/rev/1506a17832c9
>
> With it, you can use
>
>   @DOCSTRING(@ftp/ascii)
>
> to reference the docstrings in the .txi files.
>   
Ok, this is a good solution. Now to write some documentation :-)

> | 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?
>
> What does Matlab do?  Should we try to make it possible for someone to
> load an ftp object in Octave that was saved in a Matlab session?
>   
I no longer have access to octave and so I don't know.. What does matlab 
give for

fp = ftp('ftp.gnu.org');
get(fp)

I don't know if matlab provides the get accessor function for FTP 
objects and so this might just fail. The only other way to see if matlab 
stores the username/password is to read the ftp.m constructor and maybe 
modify the display method. I suppose someone could do something like

fp = ftp('ftp.gnu.org')
save ftp.mat fp

and I could read what the structure saved by the object looks like in 
Octave. In fact I suppose if we want compatibility between Octave and 
Matlab ftp objects so that objects saved in one can be used in the other 
then I'll have to do this. Someone want to run the above in matlab and 
tell me the results?

> | 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.
>
> OK.  You know I am almost always in favor of eliminating duplicate
> code...
>   
If we put the ftp oct-files in a private directory having the curl code 
as a set of class also makes it easy to split it into  a support file in 
src/ rather than in urlwrite.cc as well.


D.