On mobile data it could be beneficial if one does not finish an issue in one go.

In the next release / 1.0, I'm planning to introduce customization of the scripts endpoints via ENV vars. In addition I've added an ENV var MEPO_USERPIN_ENABLED which can be set to 0 to disable the user positioning script functionality all together. The work-in-progress documentation can be seen here: https://git.sr.ht/~mil/mepo_website/tree/master/item/src/pages/userguide.md#overridable-script-env-variables ..or you can reference the master script here: https://git.sr.ht/~mil/mepo/tree/master/item/scripts/mepo_ui_menu_user_pin_updater.sh . I think this is a nice middleground for users since most users will expect location positioning to work by default and good sensible defaults is a explicit project goal. However this allows advanced users to opt out simply by setting an ENV var. Alternatively, the user can choose not to use mepo-scripts as well if they don't desire this functionality as well as described earlier.

~amjoseph reporting of wifi BSSIDs or similar is something that'd be handled by geoclue, which is just an optional dependency and things function fine without geoclue. The script uses gpsd, geoclue, or MLS (simple curl). I don't consider this privacy-violating as you put it but users or packagers can set MEPO_USERPIN_ENABLED to 0 if necessary.

~cnx the idea about coordsvia function being customizable for device-specific-purposes is also interesting as well and I would likely accept a patch to some effect of allowing custom coordsvia functions, but I think keeping things in one-script is ideal for simplicity sake. An ENV var set that references another script in PATH or to run that serves as the coordsvia function might be one way to do this.

I think location positioning is device-specific, so it would make sense to decouple the coordsvia* functions into separate script and symlink one to mepo_get_coords.sh.

IMHO it is the easiest way to let users easily configure the service while allowing downstream to patch consistently. Moreover, we can avoid making calls that always fail on certain systems.

tinystatus might even be a better choice

Thanks! BTW the page have yet seemed to be updated.

Awesome, thanks!

• Page: https://cnx.gdn
• Size: 9.09 kB
• Scan: https://gtmetrix.com/reports/cnx.gdn/Yqi8Iaxj

I just got my own domain!

I recently got my own domain name!

Entry publication time could be retrieved from the file system.