I guess the question is how much we buffer by default before resorting to unsorted and streaming the results out. Function of machine's RAM? Arbitrary number, like 64 MB? Unbounded (probably bad)?

Unsorted per default is fine. Sorting "sometimes, when the directory is small enough" sounds strange to me. Having a wrapper or set of wrappers around http.FileServer, that sorts is indeed useful.

Unsorted per default is fine.

I disagree. I find it incredibly annoying and distracting.

Having a wrapper or set of wrappers around http.FileServer, that sorts is indeed useful.

I'd rather not bloat the API. I'd rather just make it better by default.

The reason I would not do it is that the sorting might by wrong for the user. e.g. I would prefer it to be sorted by mtime for a download.

See https://github.com/mholt/caddy/blob/master/middleware/browse/browse.go how people workaround it right now.

Getting buffering and sorting just to have it sorted wrongly for your use-case sounds like baggage we will regret to me.

Another use case is disabling directory browsing (e.g. for pure asset serving).

So honestly having a more flexible Readdir seems what is needed here as it will benefit all those cases.

"Useful" is not the baseline criterion for inclusion in the standard
library.
(Any feature that anyone would bother suggesting is at least useful.)

There's no way we can build a directory list builder that will satisfy
everyone,
yet such things are trivial to write from scratch
(the current implementation is <20 lines).

I don't see the 'browse' package you link to as a work-around.
That's a new implementation of the directory list handler.
IOW, it's the correct solution to the problem.

On 29 July 2015 at 17:40, Ingo Oeser notifications@github.com wrote:

The reason I would not do it is that the sorting might by wrong for the
user. e.g. I would prefer it to be sorted by mtime for a download.

See https://github.com/mholt/caddy/blob/master/middleware/browse/browse.go
how people workaround it right now.

Getting buffering and sorting just to have it sorted wrongly for your
use-case sounds like baggage we will regret to me.

Another use case is disabling directory browsing (e.g. for pure asset
serving).

So honestly having a more flexible Readdir seems what is needed here as it
will benefit all those cases.

—
Reply to this email directly or view it on GitHub
#11879 (comment).

I think it would be fine to use Readdir(-1). Nearly all directories are small, and more importantly the file system content is under the control of the owner of the server. If they don't want the sorting, they can use their own fork of the directory lister. If they have very very large directories, they probably have other issues.

CL https://golang.org/cl/14161 mentions this issue.