httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: modifying MIME handling
Date Fri, 10 Aug 2001 01:24:40 GMT
From: "Paul Bayley" <bayleyp@mac.com>
Sent: Thursday, August 09, 2001 10:34 AM


> At 4:03 PM +0200 8/9/01, Carlos Costa Portela wrote:
> >On Thu, 9 Aug 2001, Paul Bayley wrote:
> >
> >> Implementation in source code:
> >> There is no cost in fetching the file type so long you do it
> >> while fetching the filename (where is this done?). If you try to fetch
> >
> > IMHO,  it might be too costly to check file types. What's your
> >opinion?
> >
>
> The type information is directly associated with each file like it's creation date or
file permissions. It's not in a separate
file, database, or registry. It's cached like all other metadata. The API allows me to fetch
only what I want, namely the filename
and type (and whatever else Apache wants to know). Just pass one function the inode and you
have it. It's only 32bits.
>
> It would be no more costly than a filename which was four characters longer.

Merging this comment with...

----- Original Message -----
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Sent: Thursday, August 09, 2001 7:26 PM

> Forget 1.3.  Read apr's file_io directory, compare Unix to Win32 and OS2, and start implementing
> the Darwin specifics.
>
> Then we can expand apr_finfo_t just a bit to allow some 'extended' info, that will be
very
> platform specific.  Add some accessors to ask the non-http kind of questions (what charset
> is this file?  what content?)  And then implement a new mime module to get this metadata
from
> the filesystem, in a non-filesystem specific manner :)

... this thought, I came up with the following;

if we allow some extended-attribute pointer in the apr_finfo_t itself, palloc'ed the
size of the file name -plus- the bytes required for the 'extra info', and set up the
pointer into this area (after the fname's trailing null?)

It can either be an array of extra info pointers, pointing at the strings, or simple
ea items that look something like

typedef enum apr_finfo_eitype_e {
    APR_EXTINFO_LANGUAGE,
    APR_EXTINFO_CHARSET,
    APR_EXTINFO_MIMETYPE,
... etc
} apr_finfo_eitype_e ;

apr_finfo_ei_t {
    apr_finfo_ei_t *next;
    apr_finfo_eitype_e type;
    char *value;
}

Define what ea's are platform neutral (Language, Content-Type, Charset, etc) and useful
to the rest of the world, consistent with what we've tried doing with apr.

Therefore, we keep a single palloc of the name+info, populate where it is next-to-free,
and add an APR_FINFO_EINFO flag to ask (if it's expensive) what else we can discover
from the filesystem.  [This does NOT imply trying to derive info from the file's name!]

Don't know if this appeals, but it is a thought.  I'd be happy to start cracking on WinNT
in about two weeks (NTFS supports these sort of constructs, they don't work on FAT/FAT32
volumes or 9x at all.)

Bill



Mime
View raw message