IndexOptions enhancements (was: Re: cvs commit: apache/src CHANGES Configuration.tmpl mod_autoindex.c mod_dir.c)

[Rodent of Unusual Size <co...@decus.org>]

>From the fingers of Dean Gaudet flowed the following:
>
>On Wed, 9 Jul 1997, Marc Slemko wrote:
>
>> My preference: change the index module so you can give it a
>> strftime()/sprintf() type string that specifies what information to
>> include and how to format it.  Things could include filename, size in
>> different units, atime/ctime/mtime, owner, days since modified, etc.  I
>> think that would be cool and more useful than specific directives to
>> alter the width of this or that.
>
>Ooooh this would be nice!

    Indeed.  That's how I'm reworking it.

>Oh yeah, another feature I've frequently wanted is the ability to click
>one of the table headings and have it resort the table by that type.  Like
>fetch href="?sort=date".

    Yes, that would be nice - but I don't see how it be anything except
    an incredible performance hit for directories beyond a particular
    threshold.  You'd have to pre-load the entire directory, sort it,
    and emit it - high in CPU, memory, and time-concentrated I/O - and
    the client would be sitting there waiting until you were done.

    Not for 1.3, I don't think..

    #ken    :-)}

Re: IndexOptions enhancements (was: Re: cvs commit: apache/src CHANGES Configuration.tmpl mod_autoindex.c mod_dir.c)

[Dean Gaudet <dg...@arctic.org>]

[11]benchlark:~/apache/apache/src% grep sort mod_autoindex.c
static int dsortf(struct ent **s1,struct ent **s2)
     * linked list and then arrayificate them so qsort can use them.
        qsort((void *)ar,num_ent,sizeof(struct ent *),
              (int (*))dsortf);
              (int (*)(const void *,const void *))dsortf);

It already sorts.  I don't consider mod_autoindex something for high-end
performance hungry servers anyhow ... which is why I split it off of
mod_dir :)  sorting is like the least of its bad behaviours w.r.t.
performance.

Another fellow recently posted a mod_olgadir pointer that is faster, I
forget why.  Petr Lampa has ideas about merging mod_autoindex and mod_neg
somehow with a shared cache because the two in combo can chew. 

Dean

On Sat, 12 Jul 1997, Rodent of Unusual Size wrote:

> >From the fingers of Dean Gaudet flowed the following:
> >
> >On Wed, 9 Jul 1997, Marc Slemko wrote:
> >
> >> My preference: change the index module so you can give it a
> >> strftime()/sprintf() type string that specifies what information to
> >> include and how to format it.  Things could include filename, size in
> >> different units, atime/ctime/mtime, owner, days since modified, etc.  I
> >> think that would be cool and more useful than specific directives to
> >> alter the width of this or that.
> >
> >Ooooh this would be nice!
> 
>     Indeed.  That's how I'm reworking it.
> 
> >Oh yeah, another feature I've frequently wanted is the ability to click
> >one of the table headings and have it resort the table by that type.  Like
> >fetch href="?sort=date".
> 
>     Yes, that would be nice - but I don't see how it be anything except
>     an incredible performance hit for directories beyond a particular
>     threshold.  You'd have to pre-load the entire directory, sort it,
>     and emit it - high in CPU, memory, and time-concentrated I/O - and
>     the client would be sitting there waiting until you were done.
> 
>     Not for 1.3, I don't think..
> 
>     #ken    :-)}
> 

Re: IndexOptions enhancements (was: Re: cvs commit: apache/src CHANGES Configuration.tmpl mod_autoindex.c mod_dir.c)

[Marc Slemko <ma...@znep.com>]

On Sat, 12 Jul 1997, Rodent of Unusual Size wrote:

> >Oh yeah, another feature I've frequently wanted is the ability to click
> >one of the table headings and have it resort the table by that type.  Like
> >fetch href="?sort=date".
> 
>     Yes, that would be nice - but I don't see how it be anything except
>     an incredible performance hit for directories beyond a particular
>     threshold.  You'd have to pre-load the entire directory, sort it,
>     and emit it - high in CPU, memory, and time-concentrated I/O - and
>     the client would be sitting there waiting until you were done.

So?  If someone wants it in order then they want it in order.

The IO shouldn't be too bad for directories under a few thousand entries.
Sure, it is a bit slower, requires more memory in the server for
buffering, etc. but...

OTOH, "big directories" to me have several hundred files in (I hate Usenet
sometimes...) so my sense of scale may be somewhat different.