Proposal for std.path replacement

[spir]

On 03/07/2011 09:19 AM, Johannes Pfau wrote:
> Jonathan M Davis wrote:
>> On Sunday 06 March 2011 22:51:55 Christopher Nicholson-Sauls wrote:
>>> On 03/07/11 00:24, Jonathan M Davis wrote:
>>>> On Sunday 06 March 2011 22:09:22 Nick Sabalausky wrote:
>>>>> "Jonathan M Davis"<jmdavisProg at gmx.com>  wrote in message
>>>>> news:mailman.2280.1299459971.4748.digitalmars-d at puremagic.com...
>>>>>
>>>>>> This reminds me. I should look into mime types one of these days
>>>>>> to see what the
>>>>>> appropriate way (if any) would be to put support for them in
>>>>>> Phobos. It would be
>>>>>> nice to not have to go by extension for the few programs that I
>>>>>> have which have
>>>>>> to worry about file type.
>>>>>
>>>>> I'm no unix expert, but my understanding is that mime types in the
>>>>> filesystem don't even exist at all, and that what it *really*
>>>>> does is use some complex black-box-ish algorithm that takes into
>>>>> account the first few bytes of the file, the extention, the exec
>>>>> flag, and god-knows-what-else to determine what type of file it
>>>>> is. Contrary to how people keep making it sound, mime type is
>>>>> *not* the determining factor (and cannot possibly be), but rather
>>>>> nothing more than the way the *result* of all that analysis is
>>>>> represented.
>>>>
>>>> I thought that the first few bytes of the file _were_ the mime
>>>> type. Certainly, from what I've seen, extension has _no_ effect on
>>>> most programs. Konqueror certainly acts like it does everything by
>>>> mime type
>>>> - file associations are set that way.
>>>>
>>>> - Jonathan M Davis
>>>
>>> As someone who uses hex editors quite a bit (resorting these days to
>>> using Okteta mainly), I can tell you I have yet to see any file's
>>> mime embedded at the beginning, nor have I seen it in any
>>> headers/nodes when scanning raw.  Doesn't mean it's impossible of
>>> course, and certain file systems certainly might do this[1] but I
>>> haven't seen it yet[2].
>>>
>>> You are quite right, though, that extension doesn't matter at all,
>>> except in certain corner cases.  Even then, they are reasonable and
>>> predictable things -- like SO's having the right extension.
>>> Considering the posix convention of "hiding" files/directories by
>>> starting the name with a dot, it'd be hard to rely on extensions in
>>> any naive way anyhow.  ;)
>>>
>>> -- Chris N-S
>>>
>>> [1] I'd just about expect the filesystem of BeOS/Haiku to do so, or
>>> something similar to it at least.
>>>
>>> [2] Also not saying I wouldn't want to see it, necessarily. Done
>>> right, it'd be a damn nifty thing.
>>
>> I've never studied mime types, so I don't know much about them. It's
>> just that it was my understanding the the first few bytes in a file
>> indicated its mime type. If that isn't the case, I have no idea how
>> you determine the mime type of a file or what's involved in doing so.
>> I _would_, however, like to have a way to get a file's mime type in D,
>> so one of these days, I'll likely be looking into the matter.
>>
>> - Jonathan M Davis
>
> The mime type can be saved as meta data on some filesystems, but it's
> not in the file, it's an attribute:
> -----------------------------------------------------
> Storing the MIME type using Extended Attributes
>
> An implementation MAY also get a file's MIME type from the
> user.mime_type extended attribute. The type given here should normally
> be used in preference to any guessed type, since the user is able to
> set it explicitly. Applications MAY choose to set the type when saving
> files. Since many applications and filesystems do not support extended
> attributes, implementations MUST NOT rely on this method being
> available.
> -----------------------------------------------------
>
> If this method is not available, programs look at the content of files
> for specific patterns to guess the mime type. It's not the mime type
> that is saved in the file though. Consider an mp3 file: there's no
> "audio/mp3" in the file, but there always is a mp3 header. If a file
> is scanned and a mp3 header is found, it's safe to assume the mime
> type. Most file formats also have some kind of magic number at the
> beginning, so it's easier to detect those.
>
> More information:
> http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html

I would definitely love an inter-OS standard for storing the MIME-type in every 
file's first byte. Esp. the text encoding, when it's text (ask Walter why D 
only supports UTF's, and even then the cost in complexity just to determine 
which UTF (including byte-order!)). But we're not in such a world.
And you can be sure that numerous (super C experts) would oppose this because 
of the space cost.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com