New gnome keyring

[bilelmoussaoui]

Switches #56 to use a branch from this repo so we can easily collaborate on it.

progress to-date:

• D-Bus Secret Service API implementation - complete
• Default keyring (login.keyring) support - complete
• Multiple keyring support - not done

[warusadura]

Does it make sense to store the session along with an Item. As in,

pub struct Item {
    inner: RwLock<portal::Item>,
    path: OwnedObjectPath,
    keyring: Arc<Keyring>,
    locked: bool,
    session: OwnedObjectPath,
}

and then, store the same session inside Collection,

pub struct Collection {
    keyring: Arc<Keyring>,
    pub(crate) items: RwLock<Vec<super::item::Item>>,
    alias: RwLock<String>,
    label: String,
    locked: AtomicBool,
    created: Duration,
    modified: Duration,
    path: OwnedObjectPath,
    sessions: Vec<OwnedObjectPath>,
}

with this way we get access to all the available sessions and we can retrieve a session based on an objectpath. wdyt?

[bilelmoussaoui]

Does it make sense to store the session along with an Item. As in,

pub struct Item {
    inner: RwLock<portal::Item>,
    path: OwnedObjectPath,
    keyring: Arc<Keyring>,
    locked: bool,
    session: OwnedObjectPath,
}

and then, store the same session inside Collection,

pub struct Collection {
    keyring: Arc<Keyring>,
    pub(crate) items: RwLock<Vec<super::item::Item>>,
    alias: RwLock<String>,
    label: String,
    locked: AtomicBool,
    created: Duration,
    modified: Duration,
    path: OwnedObjectPath,
    sessions: Vec<OwnedObjectPath>,
}

with this way we get access to all the available sessions and we can retrieve a session based on an objectpath. wdyt?

Storing the session is required yes, but not just it ObjectPath. Instead you need to store the Sesssion itself which would contain more information than just the object path. Ideally we can store it as HashMap<OwnedObjectPath, Session>, same thing for collections & items I would say.