thoughts about gvfs

[nf2 <nf2 scheinwelt at>]

hi alexander,

i compiled gvfs yesterday and played with it a bit. looks nice. just 
some notes:

1) gvfs-cat on  smb: sometimes hangs.

2) why don't you map the volumes and drives into the filesystem tree 
(volumes://, drives://) this would have the advantage that you can use 
your flexible file-info structure and you don't need a special 
gvolumes.h / gdrive.h API. (because what's the technical difference 
between a mountpoint which shows up in the filesystem tree (like 
smb://server/share and a volume/drive in the volume list?)

i don't understand the reason why mounting is handled by

g_file_mount              (GFile                  *file,
                         GMountOperation        *mount_operation);

and unmounting and ejecting is handled through the volume/drive list.

wouldn't it be more consistent to have a "std:mountpointid"  and  a 
"std:capabilites" field (or "mountpoint:id" and 
"mountpoint:capabilities") in the file-info of a mountpoint, drive or 
volume and

g_mountpoint_mount(char * mountpointid, GMountOperation *eject_operation);
g_mountpoint_unmount(char * mountpointid, GUnMountOperation        
*eject_operation);
g_mountpoint_eject(char * mountpointid, GEjectOperation        
*eject_operation);

the std:capabilites could be a 64bit mask which reports the capabilities 
of a "file-system-node", like CAN_MOUNT, CAN_UNMOUNT, CAN_EJECT for 
mountpoints, but also CAN_SEEK_FILE for files...

perhaps there could also be a kind of "reverse" lookup for mountpoints...

GFileInfo * g_mountpoint_info_get_byid(char * mountpointid);

which would be valuable after mounting - to get the uri the mountpoint 
points to... (something like "mountpoint:root" field, which exists only 
for mounted mountpoints)

3) i thought about your argument against fuse again, that it cannot 
handle server side copying: isn't copying on the server-side problematic 
anyway, because you don't receive progress information? (is this also a 
problem when moving a file on an ftp server? - moving between different 
partitions?)

4) i have seen that every read/write operation generates a "job" on the 
daemon side - does that mean you have to switch beween 3 contextes - the 
client process, the main thread on the deamon side and the worker thread 
on the daemon-side?

5) just a thought about mime-type detection: would it make sense to have 
a GFileMimeTypeInputStream - to detect the file content type "on the 
fly" when reading a file. AFAIK KIO does that in it's "get" job... I 
believe that's an advantage of KIO's event based system, that you can 
have progress/mime-type events along with reading a file...

norbert