On Fri, 2007-05-04 at 09:00 -0500, Jerry Haltom wrote:
>
> Why doesn't HAL use UUIDs? I'd say probably because up until now there
> was no abstraction to turn those UUIDs into usefully understandable
> paths for the user. If you plug in a USB disk and open Nautilus, you see
> the /media/usbdisk-1 path. They needed to make that look right and
> didn't want to write a next generation VFS system like you are doing. I
> could be wrong however.
I don't understand this. Why not just
use /media/5407588e-6835-4efd-b0e9-d41a9a450093 as the mountpoint? There
is no need to use something like
media://5407588e-6835-4efd-b0e9-d41a9a450093/ instead. They are just two
different forms of the same thing, and one doesn't need any extra
software support.
> I'd like to point out that I'm not advocating UUIDs at all, actually.
> I'm advocating an abstraction for mounting and browsing removable
> devices which correspond to kernel VFS paths. It just so happens UUIDs
> are the first thing that came to mind. The GVFS idea of explicitly
> "mounting" a resource offers us an extremely good place to add such UI
> hooks. We've never had these before. There was no real good way to auto
> mount kernel VFS paths, and allow the UI to request media, so it's never
> been possible.
Ah, I guess the difference in the URI case is that its possible to
intercept the access of a non-mounted location and do something.
> Are GFile instances extensible? Can a writer of a GVFS module cause
> custom URI prefixes to return custom GFile implementations? That is
> really the only thing standing in the way of such an idea being
> implemented by me or others. To test out my idea, I would need to return
> a GLocalAndDaemonFile instance which could return NOT_MOUNTED when it
> wasn't mounted. Can I implement both mounting and local file access
> through a single GFile subtype? Or do GDaemonFiles *only* support
> mounting (mounting requiring communication with a daemon of some sort?)
> I think this is the only area where GVFS design decisions could
> potentially effect implementing this. As long as you can have a GFile
> which does both local access and manages mounting, we're good.
The default dbus implementation of GVfs doesn't allow anything like this
(ATM at least), but another implementation of the GVfs api could
generate any GFile they want in the g_vfs_get_file_for_uri() method.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat,
Inc
[EMAIL PROTECTED] [EMAIL PROTECTED]
He's an otherworldly guerilla firefighter looking for a cure to the poison
coursing through his veins. She's a sharp-shooting renegade former first lady
with a knack for trouble. They fight crime!
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
