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

 1. Getting it wrong when decoding an URI may result in security issues
    so correctness is really important

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

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

 http://svn.gnome.org/viewvc/nautilus/trunk/src/nautilus-connect-server-dialog.c?revision=14685&view=markup

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