Post by Thomas Perl
Post by Wim de Vries
I am converting my aircraft navigation app to Sailfish.
It comes (default) with OpenStreet based maps + 3D data files of
Western Europe (in RPM).
Most users will use this map, but some users may use their home
made maps (generated by a PC application).
In the latter case, the users will delete this W-Europe map (it
takes up quite some disk space).
Harbour says that I should install the app data (very much bytes
for the W-Eu map) in /usr/share/$NAME and in the first run of the
app, copy them to $XDG_CONFIG_HOME/$NAME.
But now I am stuck with an enormous amount of (useless) data in
/usr/share/$NAME that cannot be removed.
The ?copy stuff to the home directory of the user? is only relevant
if you want to e.g. ship default config files and install them to
the config directory on first start (the suggestion was put in place
when somebody wanted to install files to /home/nemo/.config/ in the
RPM file, something that will also lead to unhappy people in case of
package upgrades, and that was suggested as best practice if the
code can?t deal with missing config files - which it ideally should
;)). For big files, obviously it doesn?t make sense to copy them to
$XDG_CONFIG_HOME/$NAME. Instead, what you could do is install them
to /usr/share/$NAME, and then just have a flag in
$XDG_CONFIG_HOME/$NAME if the user wants to disable the system-wide
data (of course, this doesn?t free the data, but in case hiding/not
loading the data will improve e.g. the startup time or user
experience, it could still make sense).
For data that the package manager installs, only the package manager
should modify/remove the data. Making /usr/share/$NAME
world-writable is not allowed per harbour rules, and for good reason
- if the user would e.g. delete the pre-installed maps there, they
would re-appear every time the app is upgraded, or if the user
modifies the data there (or the app), these changes would be
overwritten by a package upgrade.
Also, another thing: Having big pre-installed data in the app
packaged (=inside the RPM) is bad, as it will require this data to
be re-downloaded every time the package is installed, and (during
installation time) will take up the space for the - temporarily
downloaded - RPM and the extracted data (you will need ~ 400 MB free
to extract a 200 MB RPM file with 200 MB of data inside, not taking
into account compression and stuff).
So, you have an app plus some big data that probably doesn?t change
as often as the code does (either it changes more often or it
doesn?t change as often - the data doesn?t usually have anything to
do with code updates to your app except if you happen to do some
data format changes).
1. Don?t ship any data with your application
- Small download and upgrade size, no wasted space
- For the ?pre-packaged? maps, you could download them in the app on first start
2. Ship data with your application, and don?t let the user delete it
- No need to host any data packages
- Package upgrades and first download will be unnecessarily large
I?d suggest you do variant 1: Users who have a good connection might
not want/need to download much data upfront, they might just want to
try out your app (=easier when it?s a smaller download) and only
after they?ve tried and liked your app, they might go into the
in-app menu and select something like ?download pre-packaged maps?.
As your data seems to be open in some sense, you might be able to
either download it directly from the OSM servers, or you package it
up and put it up on some hosting service (e.g. sourceforge.net works
well for hosting such data downloads, including mirroring - but any
other service or your own web server would work just as well).
If you really do want to ship the data with your package, it should
not be possible to delete it, only possibly hide it from the UI of
the application via a setting that is stored in
$XDG_CONFIG_HOME/$NAME. By the way, all the data that you download
should go into $XDG_DATA_HOME, not $XDG_CONFIG_HOME (as the name
suggests ? this will allow backup and cleanup applications in the
future to e.g. backup / clean only the data directory (keeping the
config in place) or only deleting only the data). For data that you
basically cache from a web services, such as map tiles,
$XDG_CACHE_HOME/$NAME might be an even better place.
Of course, you could also create a separate ?Map pack? app entry for
each pre-loaded packs that just contains the map data, although I?m
not sure if we currently accept such ?non-app? items (without a
.desktop file and icon).
For the future, if somebody wants to brainstorm it on
together.jolla.com, we could have separate ?data packages? for each
app on harbour that the store client takes care of installing and
updating independent of the app, which would also result in better
bandwidth usage (data is only downloaded when updated, app package
updates can be downloaded and installed independently). On Google
something similar to that could solve the problem in your case, but
we?re not there yet.
SailfishOS.org Devel mailing list