Re: Assuming "text/plain" for text-like MIME sniffing buffers often leads to problems



On Fri, 2006-04-21 at 12:17 +0200, Christian Neumair wrote:
> Am Donnerstag, den 20.04.2006, 17:21 +0200 schrieb Christophe Fergeau:
> > 
> > There's a bug explaining what goes wrong in the pdf case: there was a
> > change done to make gnome-vfs return MIME_TYPE_UNKNOWN when multiple
> > sniffing pattern matches (it used to return the first match I think).
> > In
> > the pdf case, s-m-i contains 2 sniff patterns for % (yep, % alone),
> > and
> > one for %PDF-, and the current code decides it's an ambiguous case,
> > and
> > return MIME_TYPE_UNKNOWN. 
> > 1) having single character sniff patterns isn't a great idea
> > 2) in ambiguous cases, we should use the mime type coresponding to the
> > longest matchinig pattern, and only return UNKNOWN if there are
> > several matches of the same length. 
> 
> Hrm I've revised my opinion on the "match longest pattern" issue.
> Shouldn't we rather use the powerful means of matchlet priority for
> letting %PDF have a bigger priority than %?

I guess that would work too, but for equal prio we'd use longest match.

> I admit that just adding a % matchlet might not have been the best idea,
> but LaTeX and matlab documents don't really have a clear header, but
> sometimes occur without any extensions. We might want to offer a
> GnomeVFS wrapper API for returning all the match candidates in such
> cases in the long term.

I'm not really sure what to do in the UI if we get multiple matches
though. We really need to pick just one type to display to the user
(icon, type name, etc).

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an uncontrollable white trash rock star with a mysterious suitcase 
handcuffed to his arm. She's a brilliant belly-dancing traffic cop from a 
different time and place. They fight crime! 




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