Tom Tromey wrote:
This updates our internal mime type database in two ways. First, we
now parse /etc/mime.types, if it exists.
IMO that needs to be factored into a VM interface. On Windows it doesn't
make sense to try to read /etc/ (and it may in fact represent a security
issue to do so).
Tom Tromey wrote:
This updates our internal mime type database in two ways.
It might be worth considering merging or incorporating JAF to do this.
--
犬 Chris Burdess
They that can give up essential liberty to obtain a little safety
deserve neither liberty nor safety. - Benjamin Franklin
Jeroen == Jeroen Frijters [EMAIL PROTECTED] writes:
Jeroen Tom Tromey wrote:
This updates our internal mime type database in two ways. First, we
now parse /etc/mime.types, if it exists.
Jeroen IMO that needs to be factored into a VM interface. On Windows
Jeroen it doesn't make sense to try
On Wed, 2006-04-05 at 09:26 -0600, Tom Tromey wrote:
Jeroen == Jeroen Frijters [EMAIL PROTECTED] writes:
Jeroen Plus on some platforms there might be a mime database available
Jeroen elsewhere.
Yeah. Actually on my Linux box I see several different mime.types
files in /etc, one of which
Mark == Mark Wielaard [EMAIL PROTECTED] writes:
Mark Note that there is a standard on freedesktop.org:
Mark http://freedesktop.org/wiki/Standards_2fshared_2dmime_2dinfo_2dspec
Mark plus an associated mime-database plus some software that is shared
Mark between different GNU/Linux dekstop
Chris == Chris Burdess [EMAIL PROTECTED] writes:
This updates our internal mime type database in two ways.
Chris It might be worth considering merging or incorporating JAF to do this.
I updated the PR (27049) with this idea.
Tom
I'm checking this in.
This updates our internal mime type database in two ways. First, we
now parse /etc/mime.types, if it exists. This code comes from libgcj
(with a small refactoring). Second, I regenerated the list of
built-in type from the mime.types on the machine I'm using now. (I
also
