Hi Marcos, I think we will drink some beer soon :)
>>I understand the rationale, but I don't see it as necessary. Lets just >>cover what is in the spec. In version 2, if we need to support this >>later, we can add it easily. It won't break backwards compat because >>we will just be expanding the range. I am not religious about the change, but I would suggest to be minimalistic in the present requirements for v2. BTW: Relevant (IMHO) excerpts from Snow Leopard and BSD: 1) macmini:folder user$ ls -X ls: illegal option -- X usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...] 2) "man ls" on Snow Leopard and BSD does not know the terms "extension" or "code" (file type code) Thanks, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -----Original Message----- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Thursday, October 22, 2009 6:12 PM To: Marcin Hanclik Cc: public-webapps Subject: Re: [widgets] Potential bug in Rule for Identifying the Media Type of a File 2009/10/22 Marcin Hanclik <marcin.hanc...@access-company.com>: > Hi Marcos, > >>>To be clear: All we want to do is check if the file extension of a >>>file case-insensitively matches one of the extensions in the File >>>Identification Table. If you can't match it, then the MIME type gets >>>resolved with SNIFF. > Ok, I understand the intention of this section. > > The ranges are an implementation detail (optimization/efficiency of some > implementation, not a MUST for all). > So in general all the comments about Unicode comparison/difficulty etc are > irrelevant. > Thus ranges as well. Ok, cool. We are in agreement. > Then the only really disputable thing is whether ".jpg" should be sniffed > (your proposal) or whether it is to be interpreted as pure file extension (my > proposal). > In my argumentation I showed that on *nix/*inux systems ".jpg" is a file > extension to support the interpretation as pure file extension. > Yes, and on my Mac, it was not. It seems more logical to me to not treat it as an extension. Look at all the .whatever files on your system. I bet you 2 beers that 99% will be text files. And I bet you will ".whatever.ext" will identify a type (like .something.plist). > The suggestion to remove ranges aims at facilitating any extensions/additions > to the spec. E.g. if we would like to add ".p12" or Unicode extension to the > File Identification Table, we should only have to add it there and not change > the processing algorithm. > I understand the rationale, but I don't see it as necessary. Lets just cover what is in the spec. In version 2, if we need to support this later, we can add it easily. It won't break backwards compat because we will just be expanding the range. -- Marcos Caceres http://datadriven.com.au ________________________________________ Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
