Re: New gvfs-backend

[Alexander Larsson <alexl redhat com>]

On Tue, 2012-09-04 at 16:48 -0400, Erick Pérez Castellanos wrote:
> Hi:
> 
> I'm trying to implement a new gvfs backend, and for that I will need
> some directions.
> So far I've pocked around into daemon folder in gvfs tree, and I've read
> some exmaples, there's stuff unclear anyway.
> 
> I know I have to implement the virtual methods of GVfsBackend class,
> right. But I would like to know which is the purpose of each one of
> those, or at least the important ones.

First of all we have the concept of a mount. There is no way to do
anything via gvfs unless it is on a mount. Mounting something means we
have a running instance of a daemon with the backend instantiated at
that particular mountpoint. The mount operation is supposed to do all
the network connection and authentication needed such that all later i/o
operations can do their work uninterupted.

Secondly, as you've seen all ops are in pairs. The gvfs code will
automatically call your try_ implementation first, and if it is
implemented and returns TRUE it will consider the job "handled" in that
your backend is supposed to directly or via async i/o and the mainloop
eventually complete the job (via g_vfs_job_succeed or
g_vfs_job_failed*). If not, gvfs will queue a call to the non-try_
version of the method inside a threadpool, and you can implement a
blocking version of the operation (make sure its threadsafe!).

Third, all the operations in GVfsBackend are triggered by GIO calls
which are then proxied to your gvfs daemon. So, to understand the
requirements and behaviour of the calls, read the corresponding gio API
docs.

Backend op details:
mount: Mount the mountpoint or fail
unmount: Finalize the mount as its being unmounted
mount_mountable: Try to mount a "mountable" file on your backend, i.e.
something like an smb share when browsing smb shares on a computer
{start/stop/eject/unmount/poll}_mountable: g_file_xx_mountable, on a
file as the above
open_for_read: g_file_read
open_icon_for_read: Open a stream to icon data for a handle you returned
in a GFileInfo
close_read: GInputStream.close()
read: GInputStream.read()
seek_on_read: GFileInputStream.read()
create: g_file_create
append_to: g_file_append_to
replace: g_file_replace
close_write: GOutputStream.close()
write: GOutputStream.write()
seek_on_write: GFileOutputStream.read()
query_info: g_file_query_info
query_info_on_read: GFileInputStream.query_info()
query_info_on_write: GFileOutputStream.query_info()
query_fs_info: g_file_query_filesystem_info
enumerate: g_file_enumerate_children
set_display_name: g_file_set_display_name
delete: g_file_delete
trash: g_file_trash
make_directory: g_file_make_directory
make_symlink: g_file_make_symlink
move: g_file_move, both src and dest inside the backend
copy: g_file_copy, both src and dest inside the backend, has default
implementation based on read/write
push: g_file_copy, src on local file, dest inside the backend,  has
default implementation based on read/write
pull: g_file_copy, src on backend, dest local file,  has default
implementation based on read/write
set_attribute: g_file_set_attribute
create_dir_monitor: g_file_monitor_directory
create_file_monitor: g_file_monitor_file
query_settable_attributes: g_file_query_settable_attributes
query_writable_namespaces: g_file_query_writable_namespaces

As to which are important. That depends on what you want. A working
read-only backend would need some version of: 
 mount, open_for_read, read, close_read, query_info, enumerate