File backend: the plan

[bilelmoussaoui]

Currently we are exposing a bit too much of what I would consider internal API. See https://bilelmoussaoui.github.io/oo7/oo7/keyring/index.html. We can easily make things public if there is a demand for that but making them private is harder as it might break existing applications out there.

What I suggest is:

• Move everything in keyring module to the portal module
• Rename keyring::api to portal::keyring
• Rename keyring::Storage to portal::Keyring
• Don't expose keyring::Result, we already have a top-level one. Once we have proper DBus error types, we could make a oo7::Error that handles both the "portal" & "dbus" error types.
• Hide most of the public constructors/methods/structs fields that are not useful for API users
• Move Key struct to the top level as It will probably shared with the dbus encrypted implementation and make it private
• Rename insert_replace to insert and provide a replace parameter. Similar to how the dbus/libsecret API works

[sophie-h]

We could also have a

enum Error {
DBus(...),
Portal(...),
}

For the convenience API. It might have some benefits like clarifying which type was used and might be nicer if someone uses one backend explicitly.

[bilelmoussaoui]

Yes, the usage of the specific backend would still be possible as their generic APIs would still be available. The higher level functions are what "most of the apps" will use though. But making every constructor takes that is meh. It is up to the library to decide what is available to use otherwise every app will have it own implementation for checking if it is sandboxed or not... not great

[sophie-h]

Agree with all points.

I'm just not sure about keyring::Storage (aka portal::Keyring). We only need it public if people want to use different keyring files. But it's lacking all the convenience functions etc. Maybe just make it private for now as well?

[bilelmoussaoui]

We only need it public if people want to use different keyring files. But it's lacking all the convenience functions etc. Maybe just make it private for now as well?

Sure, I don't think it makes sense to allow users to use different keyring files, we want them to be compatible with libsecret and so with a potential future implementation of Passwords or whatever it is called. Otherwise that is gonna be a mess.

[sophie-h]

Actually, I might want to create an app primarily to show the Flatpak keyring entries. Maybe we can make portal::keyring available under a "unstable" feature or something similar?

[bilelmoussaoui]

You mean https://bilelmoussaoui.github.io/oo7/oo7/portal/api/struct.Keyring.html? or the other one? :p

[sophie-h]

Oh, it's api now. It would need almost everything public.

[bilelmoussaoui]

I think we have most of stuff from the issue covered, we can handle other stuff individually in the future