Re: A patch for uniform mime handling

[Rodney Dawes <dobey free fr>]

On Wed, 2003-09-10 at 05:06, Alexander Larsson wrote:
> On Wed, 2003-09-10 at 06:54, Bryan Forbes wrote:
> > Hello,
> >     I am emailing this list to propose a patch to gnome_vfs_get_mime_type to return
> > GNOME_VFS_MIME_TYPE_UNKNOWN instead of NULL as it does now.  The patch on bug 121553
> > (http://bugzilla.gnome.org/show_bug.cgi?id=121553) fixes this issue and also handles it
> > the way gnome_vfs_get_mime_type_common, gnome_vfs_get_file_mime_type,
> > gnome_vfs_get_mime_type_for_data, and gnome_vfs_get_mime_type_from_file_data (by using
> > _gnome_vfs_get_mime_type_internal instead of returning NULL).  Not only does it make the
> > function more uniform to the other 4 functions, but it also fixes a crash on Solaris when
> > the function returns NULL (because you can't do printf("%s\n", NULL);).
> >     You may be saying to yourself, "This breaks API", but I would say to you that all
> > apps that use this function have to handle this anyway, and most set the mime-type to
> > GNOME_VFS_MIME_TYPE_UNKNOWN themselves. For example:
> 
> I don't like the patch as it stands. The call is documented to do the
> same thing as gnome_vfs_get_file_info(), and it is my opinion that if
> you pass GNOME_VFS_FILE_INFO_GET_MIME_TYPE to get_file_info the module
> should *always* put something in the mime field, even if it is only
> GNOME_VFS_MIME_TYPE_UNKNOWN. If some module is not doing this we should
> fix that. The file method internally calls
> gnome_vfs_get_file_mime_type() which ends up calling 
> _gnome_vfs_get_mime_type_internal() already, so its ok.

But what about for URIs of types where there is no module installed. It
would still be nice to know the mime type, so that we could open the
correct application, even if it's on a URI that gnome-vfs can't handle,
such as mms:// or rtsp://, where these would make sense to launch
mplayer, xine, realplayer, windows media player, or something else.

> I do agree that we should probably pass GNOME_VFS_MIME_TYPE_UNKNOWN if
> the get_file_info() fails though. But we shouldn't be trying to guess
> the type of a non-existing file, that will just confuse the caller,
> since i.e. launching an app to handle the file or trying to load it will
> not work.

Except for the case where get_file_info() fails because gnome-vfs
doesn't support every type of URI on the planet, and not all URI types
are meant to transfer data in a way that it would be readable as some
kind of virtual file system, such as mailto: or aim:. It also doesn't
make sense to store the protocol things in gconf, since multiple apps
can't really own the same gconf key, and specify that they all handle
that uri, so that they get presented in a drop-down list, for the user
to just choose "Evolution" or something like that.

> > At line 97 of src/egg-recent-item.c in totem cvs HEAD:
> > 	item->mime_type = gnome_vfs_get_mime_type (item->uri);
> > 
> > 	if (!item->mime_type)
> > 		item->mime_type = g_strdup (GNOME_VFS_MIME_TYPE_UNKNOWN);
> > 
> > As you can see, this code just works around the NULL return and wouldn't break with the
> > new patch. EOG, File-Roller, gedit, gpdf, nautilus
> 
> This would be fixed by passing GNOME_VFS_MIME_TYPE_UNKNOWN if the
> get_file_info fails.

Which is basically exactly what this patch does. However, it also
resorts to getting the mime type from the filename first.

-- dobey