Next: Implementation of asynchronous operations
Up: Unix file system extensions
Previous: File transfer support
Implementation of access plug-ins
As explained in 4, access methods are implemented as
dynamically loaded plug-ins. Even the file plug-in that accesses local
files is implemented as a plug-in.
Dynamic loading of plug-ins happens during GnomeVFSURI parsing (see
section 5.1): the URI is split into its #-separated subparts,
the library looks up the access method names (such as file, http and
so on), and tries to locate the corresponding plug-in library, by
using both a system-wide and a user-wide configuration file called
gnome-vfs.conf. If the library is located, it gets linked in
dynamically; otherwise, a return code is returned, reporting that the
URI is invalid.
Every access method module must provide an initialization function;
the initialization function returns a simple vtable containing
pointers to the implementations of the GNOME VFS operations for that
access method. Pointers to these vtables are stored directly into the
GnomeVFSURI object, ready for the first operation to be invoked on it.
At the time of writing, the following modules have been implemented:
- A bzip2 module, for files that are compressed with the bzip program.
- A gzip module, for files that are compressed with the gzip
program.
- An ftp method for accessing remote sites through the Internet
FTP protocol.
- An http method for accessing remote sites through the HTTP 1.1
protocol. This module also supports WebDAV.
- An extfs module, supporting Midnight Commander's generic
archive file support based on simple shell scripts. This
multipurpose module makes GNOME VFS able to deal with zip,
zoo, rpm, deb, arj and other formats.
- A gconf protocol to access the new GNOME configuration
database, called GConf.
Other modules, including a tar one, are being developed.
While this is not supported at the time of writing yet, there are also
plans to support CORBA-based access method plug-ins, possibly using
the Bonobo component model. [CORBA]
This will have important consequences:
- It will become possible to write plug-ins in any CORBA-aware
language. For example, you could have plug-ins written in Perl,
Python, or other scripting languages for which CORBA support exists.
This will make it extremely simple for people to come up with their
own special scripts for special directories or file systems.
- It will become possible to make GNOME VFS see file systems that
are implemented in a different process. The external process might
be running all the time, and would be contacted through CORBA. For
example, you see the list of active print jobs in the print spooler
as a normal GNOME VFS directory.
Next: Implementation of asynchronous operations
Up: Unix file system extensions
Previous: File transfer support
Ettore Perazzoli
2000-04-26