On Tue, 2006-09-19 at 05:06, Dan Winship wrote:
> > For example, we could be to use "//.network/" as a prefix for the vfs
> > filename namespace.
>
> Ew. OK, what's the idea with the fake-paths-instead-of-fake-URIs thing?
> As points against URIs, you say:
>
> 1. Using non-standard ones is evil.
> 2. gnome-vfs uses broken pathname-handling semantics to make things
> easier for applications.
> 3. Escaping and Unescaping is hard, but people want to do it to
> make pretty-looking names.
> 4. It makes people think gnome-vfs is more web-browsery than it
> really is.
>
> But (1) also sorta applies to using things that look like file paths but
> aren't, (2) seems like it ought to be covered by GFile ("This means you
> don't have to do tedious string operations on the pathnames to navigate
> the filesystem."), and (3) seems like it's covered by the display name
> thing ("These filenames would be ... not really presentable to the user
> as is. You'd need to ask for the display name via the vfs to get a user
> readable utf8-encoded string for display.").
>
> Another point in favor of paths over URIs might be "you can share the
> same representation between gvfs-aware and gvfs-naive apps (if you have
> FUSE)", but with the representation you've chosen, you don't even get
> that; you have to use a different path when talking to gvfs-naive apps.
>
> For points in favor of URIs, there's the fact that KDE uses them,
> various fdo standards use them, and various existing GNOME APIs use them
> (eg, the recent files api mentioned before).
Plus GtkFileSystem does, too.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
