Hey, So I had a look and a think about this -
First, I think this is such an important area for GNOME that we want to be in control of our own destiny - e.g. I don't think the problem space is well-enough understood that we want to commit to stable APIs or sharing code with others. Not yet. Maybe when all this is better understood we can start moving things to freedesktop.org and sharing interfaces with e.g. KDE, Qt or whatever. But I really don't think that we are there yet (we've seen with e.g. org.fd.Notifications what mess it can be if you standardize early). On dependencies: we are trying hard to move away from libdbus-1 and libdbus-glib-1 towards GDBus. We also don't want any deps (run-time or otherwise) on Qt or e.g. cryptsetup or dm-luks. We also really should be using the platform keyring API (e.g. gnome-keyring) whenever possible. Configuration: I don't think SQLite is at all what we want. Instead just flat key-value configuration files read from e.g. $HOME/.config/goa-1.0/accounts.conf $HOME/.config/goa-1.0/accounts.d/*conf /etc/goa-1.0/accounts.d/*conf is a lot more friendly. That way, since we'd have a stable configuration file format, vendors, sites and users can just drop (or generate) configuration files to reflect their setup [1]. And our daemon should handle file monitoring so things Just Work(tm) when that happens. We might also want to use GSettings here but I'm not sure. We probably want to embed a web browser engine for the Online Accounts panel - e.g. I don't think it's not good enough to rely on the users browser with the way e.g. OAuth2 works -- you really want to intercept the redirect URL and not have to scrape the authorization code out of a window title (as the Google OAuth2 docs humorously suggests) or have the user copy/paste it to the panel. In this case we want to use WebkitGTK+ which has WebKitWebView::navigation-policy-decision-requested signal to solve this. All this could probably be made to work in a platform-independent way (so OtherDesktop can use OtherDesktopWebView) but I'm just not sure I really see the point in that. We want all this in a single project with a single set of coherent docs. E.g. it should be possible to just clone one git repo from git.gnome.org and then you have everything you need. As equally important, docs from said project should be in a single doc area on developer.gnome.org. I don't think we want any foreign plug-in mechanism (e.g. XML files) to describe services. Instead, we should have a set of abstract base classes that e.g. Google, Facebook, Yahoo etc. backends can extend (and that way share code) and have a GIOExtensionPoint for this. We won't (of course) load 3rd party extensions from the get-go though. Maybe later. So as mentioned last week, I was already hacking on something along these lines that works this way. I'll try to get it into a shape where it can be shared Real Soon Now(tm). Thanks, David [1] : e.g. $ cat >> ~/.config/goa-1.0/accounts.conf << EOF [Account some_id] Name=Some Account Type=google EmailAddress=zeut...@gmail.com EOF _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list