Configuration file about miniserve HOT 12 OPEN

It allows to search for commands in your bash history.

from miniserve.

Ok so I had a proper long think and I agree we should have a very simple config file. I like the format proposed by @boastful-squirrel which seems to be TOML and since TOML and rust seem to go together a lot, let's use that. However, I think that we should use the config by default since that is what every other program does and it would be weird to deviate from that behavior. After all, if there is no config in place, it won't be used and there won't be a config in place without you knowing that since you have to put it in place specifically.

So, let's think about the implementation. I think the config should be searched in this order: ~/.config/miniserve/config.toml, /etc/miniserve/config.toml.
Can we auto-generate the config options from the StructOpt stuff we have in place? Would be neat and probably someone has already done that.

I don't want the config format to be visually nested (except for TOML lists) and I don't want it to have in-built versioning.

from miniserve.

@boastful-squirrel I do see your point, especially in a UNIX-like system: A UNIX program only does one thing and does it well. But not all systems are UNIX-like (Windows, obviously), and this tool is hardly an ideal UNIX program.

As for the advantage of configuration as opposed for alias/custom-commands: A configuration file is a data file and can be treated like data. It also works regardless of platform (aliases only work on POSIX shell, UNIX commands only works on UNIX-like system and .bat commands only works on Windows).

I also proposed #100, which, when combined with this feature, allows a system manager to easily manage users and passwords.

BTW, what is the "CTRL-R" that you referred to?

from miniserve.

I have trouble deciding whether I want this or not. The general idea of miniserve is that it's a simple, basically braindead easy way of serving your files in a somewhat convenient way. It grew to allow auth and uploading and now it's supposedly growing to allow for multiple auth providers at the same time.

It's a logical consequence for it to gain config file support and honestly, at this point, I'm not sure that would exceed the complexity I had originally planned for miniserve. Don't get me wrong. I use miniserve in production myself in a big company and therefore it's certainly not just a toy project to me. However, the whole reason I made miniserve is that I wanted a simple tool without too much bloat.

I'm not saying no. I'm saying I'd appreciate some discussion on this.

from miniserve.

@svenstaro Then according to the UNIX philosophy™, miniserve should not have to handle any of this (including reading configuration file, authentication, themes), rather, there should be other helper programs that handle them for you:

• Configuration file: A program that reads a config file and spawns miniserve with corresponding CLI flags. We don't have to change miniserve at all to support this.
• Authentication: Miniserve should be able to rely on external program (or module) to do authentication (for example: miniserve --auth-cmd my-auth-program.sh). This way, miniserve will no longer be burdened with adding any authentication feature anymore. Of course, you must change miniserve to support this.
• Themes: We should allow user to inject their own HTML code.

from miniserve.

I'm not saying anything about UNIX philosophy. I'm not a minimalism purist. I'm a simplicity-loving pragmatist. I know that miniserve hardly adhere to UNIX principles.

from miniserve.

@svenstaro Well, we can keep some existing feature out of convenient while also allow other programs (or modules) to extend miniserve's feature. What is great about UNIX philosophy is that it is infinitely extensible ("build program that works together") since every program is essentially a programmable function.

from miniserve.

@boastful-squirrel I'd value your input on this. I know you already said you wouldn't use it but what do you think about this in the general context of this tool and what I said?

from miniserve.

@svenstaro if we keep it as simple as possible, aka something like this

interfaces = ["[::1]", "127.0.0.1"]
port = 9999
auth = ["foo:bar", "bip:bop"]
allow-upload = true
overwrite-files = true
default-color-scheme = "Archlinux"

then why not, it might be helpful for some people (is it worth it ? Only you can tell this :)) , especially the port configuration: some people might have another application running on 8080, so for those, they have to change the port everytime. I don't know how to handle it from the command line though. When no arguments are given, I expect miniserve to run with the default configuration (no auth, no upload, etc), not the one from the configuration file. I would probably make it explicit through an argument (--use-config or something). I would also warn the user that upload is set to true, even if it's in his configuration.

I would use toml for that, as the format is very simple.

from miniserve.

Actually, now that I think about it, this feature isn't necessary, one can easily create a program that translates whatever configuration format they want into CLI arguments.

from miniserve.

Can we auto-generate the config options from the StructOpt stuff we have in place? Would be neat and probably someone has already done that.

You means using serde (toml-rs in particular)?

from miniserve.

Yes, serde would be good for this.

from miniserve.