Re: [Announce] Native offline maps: OSM Scout Server
 

Really impressed in how this offline map application works in sfos. Without doubt, one of the best solution in mobile offline navigation out there. Thanks!

Re: [Announce] Native offline maps: OSM Scout Server
 

A tons of Thanks to @rinigus of this. :)

Re: [Announce] Native offline maps: OSM Scout Server
 

I have released a new version with the changes by @mal: fixed typos found by him as well as updated his Finnish translation. Thank you @mal!

I wonder if there is someone around interested in linguistics or able to spell out pronunciation of some words. Namely, Valhalla supports US English (Pirate version) for its instructions. While a joke, its a nice one and, I think, very appropriate for Sailfish. Unfortunately, TTS software does not know how to pronounce "Arrr" and few other words. What TTS software can do, is to pronounce according to given phoneme description.

So, I would like to ask for help and maybe someone here can propose their versions for words listed at https://github.com/valhalla/valhalla/issues/891 .

In Sailfish, install mimic from OpenRepos ( https://openrepos.net/content/rinigus/mimic ) and use

to test the phonemes.

Re: [Announce] Native offline maps: OSM Scout Server
 

The best way to be compatible with the official Jolla shop ("no daemon allowed" rule) and end-users desire (background daemon), while avoiding to have 2 completely different codepaths, would be :

- always run the server in a separate process
- (which also means : design some inter-process communication. DBUS ? simple webservice ? protocole buffers ?)
- give the ability to start only that process ("OSMScout --daemon" or something)

- for the version available on openrepos.net :
pack a systemd ".service" file that only start the daemon in background

- for the version avaiable on the shop :
don't pack that file.

When UI starts, it checks (see the IPC mentionned above) if there's a daemon process answering.
If not, it launches the daemon as a child process / as just another thread of the main UI task.

On the official version it means that the service will only be available while the UI is running (even if it uses a weird IPC instead of directly calling functions).

On the openrepos version, people have the possibility to launch the daemon in background at boot ("systemctl enable OSMscout.service") and only launch the UI to monitor daemon activity.

Re: [Announce] Native offline maps: OSM Scout Server
 

Indeed, that would be a proper way of doing it. Would have to move all communication between GUI and the server to RPC then. Not too easy since it requires some redesign, but possible. I have added your suggestions to the corresponding github issue and let's see when I will get to that.

Alternative to RPC would be to add a command line switch and make some lock file. When user starts GUI, I can kill the daemon and run as GUI app. When GUI app is closed, a new daemon can be started as well. I would have to think how to ensure that its all working

Re: [Announce] Native offline maps: OSM Scout Server
 

I just released a bugfix release that handles better tile requests coming with the out-of-bounds indexes. In addition, all maps have been updated and uploaded to the data.modrana.org server. Please let me know if there are any issues with the maps or otherwise.

Re: [Announce] Native offline maps: OSM Scout Server
 

Another idea for running the server in the background would be to use Systemd Socket Activation, this way the Server would autostart if it is needed (=if a Request comes in), and could stop after a certain time of idle.
This way it would not be neccessary to waste resources if nothing is using the server, but activation would be transparent to any client app.
This would of corse imply that some proper IPC Mechanism is in place, because I don't think the "stop/start when GUI is launched" would work too well with that

Re: [Announce] Native offline maps: OSM Scout Server
 

I have never used it, have to read up on socket activation. However, from the brief look into intro blogs on it, it seems that the server code will have to be modified to accept the socket activated call. There are also questions on how to mix it with gui-started and socket-started options. Ideally, I don't want to modify the code too much and add additional split between worker and gui server threads connected via some RPC. But I'll read about this socket activation option and maybe its a solution. Seems that libmicrohttpd used in the server has some options to support it too, which is a good start.

Re: [Announce] Native offline maps: OSM Scout Server
 

@seiichiro0185, I looked into it and probably, that's a proper way to do it. Such socket activation would need a bit of code, but, at least on the paper, it doesn't seem to be anything excessive. I might be able to work around shared port by using start/stop - this would need some testing though. I am finishing up the things that I started on client side and would look into daemon mode as soon as I be ready for it (probably would start working on it by the end of this week, if all goes to the plan).

Re: 1.1.0
 

I have just uploaded 1.1.0 release.

This release adds automatic activation by systemd sockets. Thank you all for suggesting daemon mode and, in particular, @seiichiro0185 for the way to implement it. In this case, systemd's socket activation works very well and allows us to have minimal resources allocated for the server when we don't use it.

The server supports GUI and socket-activated modes. When you open the GUI, it stops the service and socket activation, waits till the server's ports get free, and works as usual. On closing GUI, socket activation is started again. If the server is started via socket activation, it runs in the background (no GUI) and would stop itself after some period of time when noone was accessing it (idle period can be set in settings).

Notice that if you access the server while switching between GUI and socket activation modes, you may get some requests ignored/dropped. This is a side effect of the implementation allowing me to avoid larger rewrite of the code. In practice, I have not seen such effect on my phone (OPX).

Enjoy using it and let me know if there are issues. The update is available via OBS, OpenRepos, and was submitted to the Harbour.