[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: New MIME release



On Sat, Jul 27, 2002 at 12:26:53PM +0100, Thomas Leonard wrote:
> On Fri, Jul 26, 2002 at 09:27:34PM +0200, Filip Van Raemdonck wrote:
> > On Thu, Jul 25, 2002 at 09:55:13AM +0100, Thomas Leonard wrote:
> > > 
> > > - After installing, the update-mime-database command is run, which
> > >   validates the data and caches it in a more convenient form.
> > 
> > I've got a few comments on this.
> > 
> > We may sort of get away with this by specifying that the user, or rather the
> > system administrator if he's not installing into ~/.mime, shouldn't modify
> > this file but edit an Override.xml file in /usr/local/share/mime.
> > Or we could add /etc/mime into the list of paths.
>
> [...]
> Certainly, no user should ever be editing the files in /usr/share/mime.
> That's for Debian packages only. We could indeed add /etc/mime to the
> list...

Rereading the section about user preferences again, I'd rather go for the
Override.xml approach.
I also think that section could use a bit different wording. Something along
the lines of the attached patch. That would make it more clear that the SMI
database (or any other mime description file, provided by whatever program)
is not meant to be configurable.
Also, I'm not sure if the part describing the use of the mime database to
tell which programs can open what mime type belongs in that section.
Shouldn't that rather go in the section describing what the xml files are?

> > Next, I haven't seen any indication as to which file takes precedence when
> > two or more in the same directory provide the same information, only for
> > when they are in different directories or if one of them is Override.xml.
> 
> Yes, there aren't any rules for this. In fact, update-mime-database sorts
> the files to ensure that the output is stable accross multiple runs, but
> that isn't documented. I don't think there's any advantage to specifying
> an order, unless we want packages fighting with each other.

That's obviously undesirable, but it'll happen anyway. Assume I'm installing
both koffice and abiword. Both install a file describing a word document
into /usr/local/share/mime, but with a different comment. Which will I see?
Or they don't agree about the magic.

This may not be the best example since the word document most likely is in
the shared database already, but the same can (and eventually will) happen
with some new file type.


Regards,

Filip

-- 
        /* Amuse the user. */
              \|/ ____ \|/
              "@'/ ,. \`@"
              /_| \__/ |_\
                 \__U_/
	-- /usr/src/linux-2.4.2/arch/sparc/kernel/traps.c::die_if_kernel()
--- shared-mime-info-0.8/shared-mime-info-spec.xml.orig
+++ shared-mime-info-0.8/shared-mime-info-spec.xml
@@ -296,7 +296,7 @@
 Further, the existing databases have been merged into a single package
 <citation>SharedMIME</citation>.
 	</para>
-	<sect2>
+	<sect2 id="s2_layout">
 		<title>Directory layout</title>
 		<para>
 There are two important requirements for the way the MIME database is stored:
@@ -567,14 +567,17 @@
 		</para>
 	</sect2>
 	<sect2>
-		<title>User preferences</title>
+		<title>User modification</title>
 		<para>
-The MIME database is NOT intended to store user preferences. Although users can edit the database,
-this is only to provide corrections and to allow them to install software themselves. Information such
-as "text/html files should be opened with Mozilla" should NOT go in the database. However, it may be
-used to store static information, such as "Mozilla can view text/html files",
-and even information such as "Galeon is the GNOME default text/html browser" (via an extension element
-with a GNOME namespace).
+The MIME database is NOT intended to store user preferences. Users should never
+edit the database. If they wish to make corrections or provide MIME entries for
+software that doesn't provide these itself, they should do so by means of the
+Override.xml mentioned in <xref linkend="s2_layout" />. Information such as
+"text/html files need to be opened with Mozilla" should NOT go in the database.
+However, using extension elements introduced by additional namespaces (like a
+GNOME namespace), the database may be used to store static information, such as
+"Mozilla can view text/html files", and even information such as "Galeon is the
+GNOME default text/html browser".
 		</para>
 	</sect2>
 </sect1>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]