octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FTP objects


From: John W. Eaton
Subject: FTP objects
Date: Mon, 30 Nov 2009 14:43:53 -0500

On 20-Nov-2009, David Bateman wrote:

| I have a fairly complete 
| implementation of the FTP object type in the attached, though have 
| several problems.

OK, I'm sorry I wasn't able to respond earlier.

| 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.

| 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.

Right, I don't think they would accept having architecture dependent
files in /usr/share.

| 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?

| 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.

| 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.

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.

| 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?).

| 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.

| 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?

| 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...

Thanks,

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]