Things to complete
------------------

Tasks and TODO items are being tracked at bugzilla.eazel.com.






-------------------------------------------------------------------
old TODO items (many of them no longer relevant):

* take a look at avfs (http://www.inf.bme.hu/~mszeredi/avfs/), it is
project similar to mc's vfs, and it is pretty well written.

* tar method, cpio method.

* GZIP write support might be broken.

* Complete HTTP support.

* HTTP-related issue: we need to figure out a way to deal with HTTP
redirections.  I.e. one should be able to know that a given `open()'
operation has caused a redirection, and the name of the new URL.

* Implement SMB support through Wayne's cool librarified Samba client
stuff (Wayne Roberts <wroberts@pwav.com>).

* Add some kind of conversation function, so that e.g. we can know
what step the op is performing.  (E.g for `open()': "connecting to
ftp.some.site.net", "logging in", "getting dir listing", "retrieving
file.tar", "extracting file.c".)

* Names containing the `#' character are likely to cause disasters.
We need to provide quoting everywhere.

* Make sure that only one module is initialized at a given time
(i.e. add a lock that must be obtained before calling the
`vfs_module_init()' function).

* Complete cancellation code, to make sure every operation can be
cancelled.  We need to be able to send signals to the helper
threads/processes.

* Add some support for reusing existing processes in the CORBA
version.  E.g. if you open `ftp://ftp.some.place.net/pub/file-1.c'
and then `ftp://ftp.some.place.net/pub/file-2.c', we should re-use
the helper process that opened the first URL for opening the second
one, so that it possibly re-uses the existing connection.  This
requires keeping a hash table containing the host name and access
method for every helper process, and avoid creating new ones when a
matching one exists.  Of course, we also need to limit killing of
helper processes so that we actually have a chance to reuse them.

API issues
----------

* If you use the CORBA version, you need to initialize your
application with `gnome_CORBA_init()'; if you use the pthread version,
you need to initialize it with `g_thread_init()'.  This is not good.

* Better hiding of private stuff.

* We definitely need an `URI context', which is basically a URI prefix
which is used for subsequent calls.  When creating a context, backends
can assume they are going to get several requests for sub-URIs
starting from that URI, and can try to optimize things.  OR maybe we
can just have a function to "lock" a certain URI.  This will make
everything easier to implement.

* The asynchronous directory reading stuff needs a timeout.  I.e. you
should be able to say "give me as many entries as possible in the
following x seconds".  This can be done in the CORBA version by using
an alarm (as the thing runs in a separate helper process, we don't
have problems with signals); in the PThread version, we can instead do
this on the master thread's side, by queueing the data as it comes
from the helper thread and dispatching it through GTK timeouts (see
gnome-fm for an example of this -- we probably don't care that there
is a notification for every element, because this is relatively cheap
with PThreads).

* Make directory/xfer calls cancellable as well.

* Check that all the important ops are implemented.

* Add missing async wrappers for all the ops.

Installation issues
-------------------

* Modules are currently installed under $prefix/lib/vfs/modules.

* We need to install the private headers: otherwise, it is not
possible to write new modules without the full gnome-vfs source code.
Maybe we need to have more than two levels (i.e. more than just
"private" and "public" headers).

Implementation issues
---------------------

* Every time you read or write asynchronously, the CORBA backend will
dynamically allocate the buffer.  This is lame: we should just
re-allocate the buffer only if the required is bigger than the one of
the previous call.

* Portability checks and fixes.  I am sure I forgot lots of details.

* Metadata key lists are passed as arrays to the API calls, but are
passed as GLists to the backend modules.  This requires conversion,
and might be a performance issue.  We should just use arrays for the
modules as well.
