The use-case difference between upstream and this fork is whether to run on a server, or locally. DatHTTPD was built to run on servers; that's why there's letsencrypt support and a metrics server built in -- things that make no sense to have in a local-only environment that doesn't rely on external nameservers. (Metrics, maybe, but different metrics.)
If I'm going to start removing features, I should rename the project after a substantial reductive PR is merged. I have a name in mind. Here are the features I'd remove:
[x] letsencrypt support (ex: lib/lets-encrypt.js and references to it)
[x] metrics server (ex: lib/metric and references to it)
[x] use of yaml for configuring site. (switch to using attributes of a json file via toiletdb and modifying them via CLI)
[x] set localhost to true by default in the config.
I would feel weird about changing the license, but I would update any authorship fields to reflect shared creatorship and new maintainership.
The use-case difference between upstream and this fork is whether to run on a server, or locally. DatHTTPD was built to run on servers; that's why there's letsencrypt support and a metrics server built in -- things that make no sense to have in a local-only environment that doesn't rely on external nameservers. (Metrics, maybe, but different metrics.)
If I'm going to start removing features, I should rename the project after a substantial reductive PR is merged. I have a name in mind. Here are the features I'd remove:
lib/lets-encrypt.js
and references to it)lib/metric
and references to it)localhost
to true by default in the config.I would feel weird about changing the license, but I would update any authorship fields to reflect shared creatorship and new maintainership.