Miklos Szeredi wrote:
are there any plans (or ongoing efforts) for writing a fuse management
library for desktop integration / gui based mounting/umounting?
No, I don't have knowledge of such plans.
ok. anyone who wants to help me? perhaps we could call it "libfusi"
(fuse management interface)
what IMHO the library should do:
* maintain a list of "known" network shares/fuse mountpoints (like
fstab, but as key/value config-files in the users home directory)
Sounds sane. Though I don't see anything wrong with using the fstab
format for this
don't know ... i thought key/value style is more flexible / easier to
parse (glib). but fstab format would also be possible. also depends if a
single process takes care of this (otherwise multiple config files in a
directory (~/.config/fuse/tab ) are better)
* create, mount, unmount, remove fuse mountpoints
mkdir, exec filesystem, exec fusermount -u, rmdir
I don't see what extra a library could do
the main purpose of an API would be a wrapper layer for convenience,
providing a consistent model to deal with all kind of fuse-modules.
writing/parsing config-files, constructing cli args and launching
processes is a difficult and error prone...
think of it as a kind of MVC (model-view-controller) design: the library
provides the model/controller and the desktops the view (gui-interface).
AFAIK fuse also lacks a method to query which backends are installed,
and how to launch them (description, name of the executable,
parameters). i believe fuse-modules should perhaps install files in
/etc/fuse/modules which describe their capabilities...
* provide a list of currently mounted fuse mounts (like mtab)...
What's wrong with mtab or /proc/mounts?
nothing, but i believe filtering mtab and emitting change-signals should
be handled by the management library internally...
* password callbacks (needs support in libfuse or a second library
linked into fuse modules, because the current way of specifying
passwords as command line args is unsecure)
A nice model for this is ssh-askpass, no need to support anything in
libfuse for this to work.
hmm. would there be other options to hide the password from the
command-line? for instance setting the password in the environment or
read it from stdin? i'm looking for a kind of generic model which works
for all fuse-modules...
* a progress/logging interface for fuse-modules to send messages to an
ui-server
Yeah, libfuse needs a logging interface. fuse-2.8 maybe...
* emit mount/umount events to all clients of the management system
inotify supports this, doesn't it?
sure - just for convenience this should be provided by the library...
(because you have to monitor mtab, the fuse-fstab (or config files)...)
* translate from uri's to mountpoints back and forth (by using the list
of "known" fuse-mounts)
ftp://[EMAIL PROTECTED]/dir/file ->
~/netvols/ftp_user_at_server/dir/file (i believe the dir-name of the
mountpoint should be defined by the user, but we could offer him/her a
"proposed name")
Makes some sense, but this is definitely not libfuse stuff.
sure. everything except fixing the authentication (hiding passwords)
would be just a wrapper layer...
* get meta-information about fuse-mounts
Huh?
not sure either ... perhaps things like the encoding of filenames, seek
support,...
* provide a "browsing" interface (smb network/servers)
Why is this special? Reading the directory should just list the
servers, services, etc. fusesmb for example does this without
problems.
i was referring to the thing called "crawler" in fusesmb. can you mount it?
http://www.ricardis.tudelft.nl/~vincent/fusesmb/
the fuse management system should consist of three parts:
* a glib main-loop based client library (async mount/umount operations,
events)
* a dbus service (session bus)
* an (optionally linked) library used in fuse modules for authentication
callbacks and progress/logging events
a reference implementation of a GUI-based management client would also
be cool... (GTK+ ?)
i am working on a desktop independent vfs library
(http://www.scheinwelt.at/~norbertf/devel/vio/),
I don't quite understand what this is. Is it a replacement for the
kio/gnome-vfs stuff?
yes. but i'm not sure how popular this "vio" project is going be. the
new "gvfs", which is currently developed as replacement for Gnome-VFS,
might also be an option. but that depends if KDE accepts "gvfs" as
sub-system for KIO (i.e. "gvfs" becomes the standard library for desktop
file-management)...
regards,
norbert
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
