RE: [widgets] Potential bug in Rule for Identifying the Media Type of a File

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.hanclik@access-company.com

-----Original Message-----
From: marcosscaceres@gmail.com [mailto:marcosscaceres@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.Hanclik@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.

Received on Thursday, 22 October 2009 16:27:58 UTC