Feedback wanted on new flatpak purchases support

[Philip Withnall]

Hey,

Sorry for the delay in replying about this. It all looks pretty cool;
nice work!

On Thu, 2019-11-28 at 16:49 +0100, Alexander Larsson wrote:
> I'm interested in feedback on the overal approach here, as well as
> APIs and how well it covers what people need for flatpak.
> 
> The authenticator dbus APIs are documented here:
> 
>   
> https://github.com/flatpak/flatpak/blob/master/data/org.freedesktop.Flatpak.Authenticator.xml

Doesn’t seem to include any handling for collection IDs — what do you
have in mind for the control flow when someone’s doing a P2P pull (even
in the case where that P2P pull ends up being satisfied by a remote web
server rather than a LAN peer or USB stick)?

> The libflatpak APIs for frontend integration, are documented here:
> 
>  
> https://flatpak.readthedocs.io/en/latest/libflatpak-api-reference.html#FlatpakTransaction

The only new stuff there are the FlatpakTransaction::webflow-start and
FlatpakTransaction::webflow-done signals, right?

Presumably that means that if an authenticator uses its own UI (rather
than a URI), it just asynchronously does that part-way through
flatpak_transaction_run(), and the transaction blocks until it
completes. That seems fine, but what if the FlatpakTransaction is being
run by a background service and doesn’t want to cause UIs to pop up?
Perhaps there should be a ALLOW_INTERACTIVE or DISALLOW_INTERACTIVE
flag passed to FlatpakTransaction (and from there, passed through to
the authenticator)? If interactivity were disallowed, and the
authenticator required it, then authentication should fail.

cf. G_DBUS_CALL_FLAGS_ALLOW_INTERACTIVE_AUTHORIZATION

---

Those are just my comments from reading through all the lovely,
excellent documentation you linked to above; I haven’t compared it
against the previous design document (in Google Docs) and won’t have
time to do so.

Philip