Help request: Server - client app shared data location

I have a server that creates a database and several client apps that will share this database and I am struggling with achieving this. Any advise?

Thanks Scarlett

Where does the server creates this Database? If the server can create it somewhere in home, then it’s easy. I think in the context of snaps, $HOME is the best choice.

EDIT: Is this regarding the PIM apps?

I think HOME is a rather bad choice here (people could disconnect the home interface (and this happens more often than you think in i.e. enterprise installs), you can not make the file hidden so all of a sudden you find a file called akwutrciut.db (or whatnot) in your home and don’t know what it is) … you want to use SNAP_USER_COMMON or SNAP_COMMON rather and patch the apps to use the correct location internally …

Thanks! Working with the PIM devs to set the location of the akonadi.db thanks all.

2 Likes

How can one snap access another snap’s SNAP_USER_COMMON?

Oh, right, i missed to mention that you should indeed use a content interface if both sides are snaps (for non snapped clients you just need the location)

For the content plug, will not the data be read-only?

The akonadi ( server snap ) is a content interface. The clients are snaps as well that will connect to server. The server is currently trying to write the DB in Database: "/home/scarlett/snap/kaddressbook/x1/.local/share/akonadi/akonadi.db which it then complains Query error: “attempt to write a readonly database Unable to execute statement”

You indeed need to set the write attribute to allow writes …

WDYT about XDG_RUNTIME_DIR? This way, even non-snapped apps can also interact?

And your DB will vanish when you log out or reboot :wink: XDG_RUNTIME_DIR is a tmpfs …

Uhhh… right… my bad… :disappointed_relieved:

Ah ha! Silly me, thank you

I still believe $HOME is the best option keeping the modularity in mind. We can simply add $HOME/.kde or some similar place as a rule in a plug and even if a user disconnects home plug, that’ll not affect it.

What’s wrong with using the dir and interface that were designed for this use case ?

You just put it in $SNAP_USER_COMMON and share it with the content interface, as discussed above

Apps, outside of snap ecosystem can interact with that data too then.

BTW, can we share any directory via content interface?

Apps outside the snap ecosystem can surely access ~/snap/ too if they want to without having to add extra complexity to the snap side of things…

See the doc, the content interface can share pretty much everything from libs over data to sockets and executables … for the latter you need to be cautious though since an executable might need depending libraries the sharing snap contains, so you would need to share these too and make sure the consuming snap has them in its library path… (The gnome and kde-neon extensions do exactly that FWIW)

I don’t think it’ll add extra complexity to the snap side. If it’s stored in $HOME/.kde/ or $HOME/.local/share/akonadi.db we can simply add this path in desktop interface with write access. Or may be in the accounts-service plug, as the plug was designed for these kind of things. WDYT?

No, I meant, can we share $SNAP_USER_COMMON or folders like that?

Well, I told you what I think a few times now :smile:

IIRC you can share anything the snap owns and has access to (though I don’t think you can share stuff the snap only has access to via some other interface, that might cause issues if the consuming snap doesn’t have the same permissions if it isn’t using the very same interface)

1 Like

I am making progress using this approach.

2 Likes