Re: Best practices for using GOA

[Bastien Nocera <hadess hadess net>]

On Thu, 2018-06-28 at 10:57 +0000, Debarshi Ray wrote:
> Hey,
>
> On Tue, Jun 26, 2018 at 10:35:42AM +0200, Bastien Nocera wrote:
> > The problem here, unless I am mistaken, is that the API for
> > applications that consumes those accounts makes no difference
> > between
> > an account disappearing because it was removed, and the object
> > disappearing from the ObjectManager because the whole daemon went
> > away,
> > you receive an "object-removed" signal in both cases.
>
> That's right.  The client library is a thin wrapper around
> GDBusObjectManagerClient, and GDBusObjectManager::object-removed gets
> mapped to GoaClient::account-removed.
>
> > With a bit more work on the GOA client library, that difference
> > could
> > be made, and the account wouldn't be removed by end-user apps in
> > the
> > case of the goa-daemon going away (just disabled, and data kept),
> > and
> > the data removed only when the account is actually removed as a
> > user
> > action.
>
> Yes, I also think we should do this.  It's not clear to me whether an
> application (or anything else for that matter) stands to gain
> anything
> from knowing that the daemon went away, and if not, then it's
> puzzling
> why it was done this way in the first place.
>
> (It's one of those things that I wish I had the chance to hash out
> with David before he left GNOME.)

It was done this way because the GOA API is just a small shim on top of
the ObjectManager API. Ideally, you would block those signal emissions
if they were synthesised because of the daemon disappearing.

The ObjectManager API isn't so great when you have data on the client
side. We also use this API for BlueZ/gnome-bluetooth, and there's no
storage on the gnome-bluetooth side, so an "object-removed" translates
to hiding the device, whether or not the daemon is running. We would
need to add a similar technique to the one you should use in GOA if we
did have something stored on the gnome-bluetooth side though.