Re: thoughts about gvfs

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-04-04 at 16:50 +0200, nf2 wrote:
> hi alexander,
> 
> i compiled gvfs yesterday and played with it a bit. looks nice. just 
> some notes:
> 
> 1) gvfs-cat on  smb: sometimes hangs.

I've seen that too. I wonder what causes it.

> 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've been thinking about this too. Clearly the GFile abstraction has to
handle everything that a GDrive/GVolume does, as things like this will
appear in a virtual filesystem. A common example would be the smb shares
when browsing a server. However, even with that I think that there is a
need/want for a clearer separate API for enumerating volumes and drives.

There are a couple of reasons:
* In many cases its just a nicer API than pretending these are files.
For example when doing lists of volumes in the fileselector sidebar.
* Sometimes you don't want to show all volumes/drives (example: don't
show automounting drives on the desktop). Its easier to extend the
drive/volume API for handling this than when pretending they are files.
* Its hard to express the drive <-> volume relationship for files.
* Some users of libgio will not use gvfs, while still wanting to
enumerate volumes for the fileselector. The canonical example is
windows, where we want an implementation of GVolumeMonitor that is
native to win32 (showing drive letters and what have you), where gvfs
(the dbus stuff) isn't used.

> 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

The exact handling of mount/unmounts is very much not finished. I think
something similar what you propose will be there when its done.

> 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?)

That sure is a problem. Some backends just don't let us get progress
info. I still think that is better than making the operation possibly
*much* slower. We can still show a ping-pong sort of progress dialog.

> 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?

in-process thread switches are not full context switches. They are much
much cheaper. Also, any backend that is implementable with async i/o
only will not cause a worker thread. The same is true if the method
result can be returned immediately from the cache.

> 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...

Mime type detection by sniffing is a unix only thing, requiring the xdg
shared-mime data. I switched instead to using "content types" which is a
platform specific kind of type-string. On unix its a mimetype, but on
windows its an extension, and i think macosx will use their own system
(UTI). So, we can't in general assume we're using sniffing. 

I guess we can do it if possible though. Thats quite possible to do with
g_file_input_stream_get_file_info().

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a maverick alcoholic cowboy who knows the secret of the alien invasion. 
She's a green-fingered green-skinned archaeologist on her way to prison for a 
murder she didn't commit. They fight crime!