[fuse-devel] fuse desktop integration / management library

[nf2]

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://user@server.org/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