need decoding URI utility
Submitted by David Zeuthen
Link to original bug (#555490)
Description
In order to implement the "connect to server" feature in Nautilus, some API is needed to decode URIs.
Specifically this is needed for the "edit connected server" property page; for example given the URI sftp://user@server.local:22222/path/to/files we want to present this as
General Server: [server.local ] Name: [My share at server.local ] Icon: [some-icon-name ]
Optional User: [user ] Port: [22222 ] Folder: [/path/to/files ]
It turns out code for decoding URIs is already in gvfs
http://svn.gnome.org/viewvc/gvfs/trunk/client/gvfsuriutils.h?revision=1034&view=markup http://svn.gnome.org/viewvc/gvfs/trunk/client/gvfsuriutils.c?revision=1558&view=markup
since it's needed for the mount daemons itself. As discussed with alexl on IRC, there's a couple of things about this code
-
Getting it wrong when decoding an URI may result in security issues so correctness is really important
-
URIs may sometimes be gvfs specific (see bug 530654 and bug 528670 for lots of discussion about this). It's not impossible that some other set of gio extensions than those found in gvfs may one day be used. Such extensions may have a different way of decoding e.g. http URIs.
-
Win32 got a http gio backend that may use different URIs than in gvfs
Point 1. and the fact that the mount daemons itself using the code, is actually a reason we want this low in the stack. E.g. we want the same behavior (including bug-by-bug compatibility) in the mount daemon (implementing the mount) as well as dialogs for configuring the URI.
Point 2. and point 3. suggests we need to use an extension based system that allows e.g. gvfs to provide one set of decoding functions and e.g. another set of gio extensions to provide another.
For the API, the existing stuff in utils/gvfsuriutils.[ch] seems OK from a high-level point of view. We probably want it to be a bit more GObject'ified but that's more a detail than anything.
To support adding new URI types without having to patch the UI tools, we probably also want a way to enumerate the different supported URI types, so one can write something like
GList *supported_uri_types, *l; supported_uri_types = g_decoded_uri_get_provider (); for (l = supported_uri_types; l != NULL; l = l->next) { GDecodedUriProvider *provider = G_DECODED_URI_PROVIDER (l->data); GDecodedUriFlags flags; char *display_name;
flags = g_decoded_uri_provider_get_flags (provider); display_name = g_decoded_uri_provider_get_display_name (provider);
/* Use display_name to build a GtkComboBox for the user to * select the type of the URI. * * Use flags to choose what goes into the dialog. */
g_free (display_name); g_free (scheme); } g_list_foreach (supported_uri_types, (GFunc) g_object_unref, NULL); g_list_free (supported_uri_types);
with GDecodedUriFlags including
G_DECODED_URI_FLAGS_SHARE G_DECODED_URI_FLAGS_PORT G_DECODED_URI_FLAGS_USER G_DECODED_URI_FLAGS_DOMAIN
This is pretty similar to what's going on in Nautilus's connect to server dialog, e.g. this code
Implementation-wise I suspect that the gio bits simply just instantiates all sub-types of, say, GUriDecoder. That way, gvfs can provide this through it's gio extension. Or something to that effect.
I'm willing to write the code if something like this will be accepted in gio. Thanks for considering.
David