On Fri, 2008-02-01 at 17:48 +0100, David Faure wrote:
David Faure wrote:
However I just had a case where take subclass might be needed:
when the *magic* conflicts. Try !--foo--htmlbar/html: this should
be detected as text/html, but it's detected as application/xml here
because
David Faure wrote:
However I just had a case where take subclass might be needed:
when the *magic* conflicts. Try !--foo--htmlbar/html: this should
be detected as text/html, but it's detected as application/xml here because
both mimetypes have match value=lt;!-- type=string
On Mon, 2007-09-17 at 22:16 +0200, David Faure wrote:
On Tuesday 28 August 2007, Alexander Larsson wrote:
On Fri, 2007-08-24 at 16:44 +0200, Alexander Larsson wrote:
This is my main problem with hi-priority sniffing. It either causes very
bad performance behaviour in the file manager, or
On Mon, 2007-10-15 at 16:59 +0200, David Faure wrote:
Hi,
Wow it's been a month already... been too busy to be able to answer before,
sorry about that.
No problems. I've been pretty busy too. :)
I think this sounds fine to me. There is only one more thing that I
think needs to be
Hi,
Wow it's been a month already... been too busy to be able to answer before,
sorry about that.
On Thursday 20 September 2007, Alexander Larsson wrote:
On Wed, 2007-09-19 at 21:53 +0200, David Faure wrote:
On Tuesday 18 September 2007, Alexander Larsson wrote:
Agreed. Do we also agree
On Wed, 2007-09-19 at 21:53 +0200, David Faure wrote:
On Tuesday 18 September 2007, Alexander Larsson wrote:
On Tue, 2007-09-18 at 11:18 +0200, Patryk Zawadzki wrote:
On 9/18/07, Alexander Larsson [EMAIL PROTECTED] wrote:
Isn't just enough to check if either of them is the subclass of the
On Mon, 2007-09-17 at 22:03 +0200, David Faure wrote:
We should also make sure that we add all possible conflicting extension
matches to the database. For instace, if we add *.pdf to
application/x-gzpdf then we could use sniffing to resolve which one it
is.
I agree. My unit test for
On Tue, 2007-09-18 at 00:51 +0200, David Faure wrote:
On Tuesday 28 August 2007, Alexander Larsson wrote:
If several globs matches, and sniffing fails, or doesn't help:
fall back to the first glob match
(maybe we should do something better here?)
Hmm, I just found the case of
On Mon, 2007-09-17 at 22:03 +0200, David Faure wrote:
We should also make sure that we add all possible conflicting extension
matches to the database. For instace, if we add *.pdf to
application/x-gzpdf then we could use sniffing to resolve which one it
is.
I agree. My unit test for
Am Dienstag, den 18.09.2007, 00:51 +0200 schrieb David Faure:
On Tuesday 28 August 2007, Alexander Larsson wrote:
If several globs matches, and sniffing fails, or doesn't help:
fall back to the first glob match
(maybe we should do something better here?)
Hmm, I just found the case
On Thu, 2007-08-23 at 01:27 +0200, David Faure wrote:
On Friday 27 July 2007, Sanel Zukan wrote:
Thank you for replies.
Yeah, I also found that too, when checking my chemical MIME types list.
Seems, priorities of 50 are enough for magic patterns. Should the spec
be adjusted? What do
On Friday 24 August 2007, Alexander Larsson wrote:
On Thu, 2007-08-23 at 01:27 +0200, David Faure wrote:
The KDE 4 implementation follows the spec as much as possible, i.e. the
algorithm (in KMimeType::findByUrl) is roughly
1) find from mode_t if set (leads to inode/*)
2) try
On Fri, 2007-08-24 at 15:39 +0200, David Faure wrote:
I understand what you mean... I'm not sure what's the best behavior though;
your mail made me realize that I did skip high-magic-beats-extension in the
delayed-mimetype-determination code (even though the core mimetype code can
do that),
After discussion with Alexander Larsson on IRC, I would like to suggest a
change to the shared-mime specification, more precisely to the algorithm for
determining the mimetype of a file, when the extension isn't enough
information.
After matching high-priority rules, and assuming none matched,
One other reason is performance. Magic detection is extremely seek heavy
and thus performs extremely bad.
Yea, correct indeed.
A more significant problem is that network protocols do not support
parallel connections and thus sniffing without lag, and we have to
resort to extensions anyway
Am Mittwoch, den 01.08.2007, 07:20 +0200 schrieb Alexander Larsson:
Given all the people swearing about the current gnome mime warning
dialog I'd say it get things wrong often enough to matter.
Often this is due to complicated contailer formats (like avi or mov)
rather than someone messing
On Fri, 2007-07-27 at 20:11 +0200, Sanel Zukan wrote:
Thank you for replies.
Yeah, I also found that too, when checking my chemical MIME types list.
Seems, priorities of 50 are enough for magic patterns. Should the spec
be adjusted? What do you (people in general) think about this? I
PROTECTED]
From: [EMAIL PROTECTED] on behalf of Sanel Zukan
Sent: Fri 7/27/2007 8:11 PM
To: [EMAIL PROTECTED]
Subject: Re: Shared-mime checking order
Thank you for replies.
Yeah, I also found that too, when checking my chemical MIME types list.
Seems
Alexander Larsson wrote:
Gnome currently doesn't look at the priorities at all I believe.
GNOME prioritizes applications from
/usr/share/applications/defaults.list.
SuSE has a script, which creates this list as a heuristics from all
available desktop files.
It would be nice to have
On Fri, 2007-07-27 at 10:41 +0200, Stanislav Brabec wrote:
Alexander Larsson wrote:
Gnome currently doesn't look at the priorities at all I believe.
GNOME prioritizes applications from
/usr/share/applications/defaults.list.
That is something completely different. I.e. the prioritization
Thank you for replies.
Yeah, I also found that too, when checking my chemical MIME types list.
Seems, priorities of 50 are enough for magic patterns. Should the spec
be adjusted? What do you (people in general) think about this? I mean,
the spec was written to have a standardized way to
Hi to all,
In shared-mime specs one of the recommended ways to check file type is
given with:
if no explicit type is present, magic rules with a priority of 80 or more
should be tried next.
My intent is not to start discussion if proposed order is correct or wrong
but to see how others
22 matches
Mail list logo
