I'm not at all keen on this approach.

Personally I'd rather have files that specify file associations rather than renaming nds files to the extension they can handle. This approach is going to lead to duplication of binaries for no better reason than they support multiple file formats.

This isn't plugin support either.

I'm not at all keen on this approach.

No problem, I'll rework this to be something better.

Personally I'd rather have files that specify file associations rather than renaming nds files to the extension they can handle. This approach is going to lead to duplication of binaries for no better reason than they support multiple file formats.

I've got a few ways in mind:

1. One big text file that specifies extension-to-handler mapping. It would look something like:

   mp3: mp3-player.nds <extra arg>
   m3u: mp3-player.nds <different arg>
   avi: avi-player.nds
   

   Pros:

   • Only one file to open and read at startup
   • One place to direct users to edit

   Cons:

   • Installation of (some) homebrew is no longer as easy as dropping a file in a directory, as users must edit the handler mapping file.

2. One file per .nds that specifies extensions that the .nds can handle. E.g. for a homebrew named program.nds that can handle .mp3 and .m3u files it would be named program.ext and contain:

   mp3: <extra arg>
   m3u
   

   Pros:

   • Drop-in installation of handler mapping files

   Cons:

   • Need to read and parse every handler map at startup
   • Potential conflict if two homebrew can both handle the same file extension
   • More complicated syntax

3. One file per extension, the contents specify which .nds to open. E.g. for the same homebrew as before, there would be two files: mp3.ext and m3u.ext, and both would contain:

   program.nds <optional extra args>...
   

   Pros:

   • Drop-in installation of handler mapping files
   • No conflicts possible
   • No need to read and parse every handler map at startup because the file extensions that can be handled are given directly from the file names
   • Possibility to add extra args to command line
   • Syntax is the same as .argv files, with the file-to-be-opened tacked onto the end

   Cons:

   • More files in the file system
   • Don't know if the handler exists until trying to start it

I prefer approach 3, but let me know if you have a different preference.

This isn't plugin support either.

Naming is a hard problem in computer science and "plugin" was just the first thing that came to mind. We can go with "handler" (as above) in the documentation, or something different if you prefer.

Also, what are your thoughts on changing the startup directory based on the presence of plugins/handlers (commit b8c3131)?

Superseded by #6