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
_______________________________________________
gnome-vfs-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
