[SailfishDevel] Next meeting on SailfishOS, open source, collaboration: 9 September 2014 - 15:00 UTC

[Chris Adams]

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.