cryptomator / integrations-api

API for optional services, such as system keychain integrations
GNU Affero General Public License v3.0
12 stars 4 forks source link

Where to implement a cross-platform backend? #2

Closed purejava closed 3 years ago

purejava commented 3 years ago

secret-service and kdewallet are linux backends and therefore reside in integrations-linux.

The same for Windows Data Protection and macOS Keychain, they live in -win and -mac.

One advantage of that separation is that packaging of installers and the Appimage can consider platform specific backends and exclude them from non-relevant platforms.

I‘d like to implement access to KeePassXC into Cryptomator, which is available cross-platform.

Do I just add it to one of the existing integrations?

I suspect, that you would prefer something like integrations-crossplatform.

overheadhunter commented 3 years ago

Code that integrates a third party tool by implementing one specific interface of this lib should go into a separate library. I think this offers the best modularity for plugins. As a proof of concept the user can add the jar manually to Cryptomator. Later we can think about some UI to load jars from some Maven Repo at runtime automatically.

So for this example, I would suggest you create a new lib e.g. with Maven coordinates org.purejava:keepassxc-cryptomator. (Or keepass-cryptomator if the API works for all keepass flavours.)

purejava commented 3 years ago

A lib for accessing KeePassXC is already ready to be included. This is specific for KeePassXC and not generic for the keepass family, but not specific for Cryptomator also.

So the way is to create another lib org.purejava:keepassxc-cryptomator? I thought the integrations-... are the way to add new backends? How could this new lib be integrated? Which interfaces of Cryptomator should it access?

Sorry, I am confused now.

overheadhunter commented 3 years ago

Imagine 20 different implementations for various password managers, all residing in the same integrations-crossplatform jar. This would foil all the modularity again. The idea behind facilitating the service loader api is to allow a variety of jars simply be added to the installation without hard-wiring anything other than integrations-api.

purejava commented 3 years ago

Ok, now I got you. Thanks for your quick replies.