Hi, Due to the time of the meeting, I don't think I'll be able to attend tonight but I wanted to give my perspective on one question asked by Lucien:
>For example, there is a Sailfish.Accounts component while we >already have libaccounts in Nemo side. I would like to discuss about why >is there a separation, if it is needed (legal reason ? technical reason?) Sailfish.Accounts should not exist. Currently it provides two things: 1) QML bindings for accounts&sso libraries (with some API sugar) 2) Migration tool for when we change settings/services and need to update existing accounts on device. The bindings exist purely because the upstream QML bindings (developed by the accounts&sso maintainer, sponsored by Canonical) were not complete / usable at the time that we originally needed them. We should port our internal code over to using those upstream bindings now that they are complete -- but this would take time + testing effort. The migration tool should be moved into jolla-settings-accounts, probably, as it's an internal tool for internal use. jolla-settings-accounts has code in it (account factory, etc) which would need to be ported from using the API sugar in Sailfish.Accounts to the normal libaccounts-qt API, too, in order to remove the Sailfish.Accounts dependency. Aside from j-s-a, I don't believe any internal component depends on Sailfish.Accounts as I spent some effort porting stuff away from it in a previous iteration (eg sociald, some internal transfer engine plugin, the jolla-store application etc), but I may be wrong about that. So, TL;DR version: the separation is historical, not legal or technical. To undo the separation requires a non-trivial amount of work. Cheers, Chris. _______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
