[SailfishDevel] Sharing a common OfflineStorage DB between multiple Sailfish apps.

[christopher.lamb at thurweb.ch]

Hi Thomas

Thank you for your answer.

Zitat von "Thomas Perl" <th.perl at gmail.com>:

>
> ....
> If we can fix the offline storage path to be correct everytime,  
> we’ll probably introduce these changes into libsailfishapp, so that  
> application developers don’t have to worry about manually setting  
> this all the time (and you can still override this if you want, but  
> you should not [need to]).
>

Does this not work already? If I did not explicitly call  
setOfflineStoragePath, the DB was created happily enough in a  
subdirectory of the app without me having to do anything.


Yesterday I experimented further, and arrived at this using QStandardPaths:

     QString storagePath =  
QStandardPaths::locate(QStandardPaths::GenericDataLocation, QString(),  
QStandardPaths::LocateDirectory) + "landedcommon";
     view->engine()->setOfflineStoragePath(storagePath);

What are the pros and cons of using QStandardPaths as opposed to XDG  
Environmental Variables?


Zitat von "Thomas Perl" <th.perl at gmail.com>:

>
> ....but append  the name of your application (harbour-myapp) to the  
> path, so that all your application-specific data ends up there.

In my specific case I want this data to be available to a family of  
apps, which implies that I can't really use the app name as you  
suggest. I think I could either
a) use something like "landedcommon" as above - which is not the name  
of any of the apps in the family.
b) use the name of the primary app in the family. But this would mean  
that the secondary apps would have hard-coded references to an  
external app (not $APPNAME).
c) ensure that all apps in the family follow a standard naming pattern  
(e.g. harbour-landed-pilot, harbour-landed-settings,  
harbour-landed-recovery), and then create the common directory as a  
substring of $APPNAME.

This raises a greater architectural question: How should families of  
closely related apps be structured?
a) As one package, but with multiple executables

b) As separate packages, but able to share "stuff" within the family  
of apps: e.g. config data / local storage, shared libraries.
The shared libraries is especially important: Given the restrictive  
harbour rules we have to bundle not-yet-kosher libraries within an  
app. It would wasteful to have to repeat this for each member of an  
app family if they use the same libs.

In my case each of the apps is a full app in its own right, with a  
GUI. Others have raised similar questions about app-and-daemon pairs.

Grüsse

Chris