Hi David, On 04/27/2011 07:10 PM, David Zeuthen wrote: > On Wed, Apr 27, 2011 at 10:52 AM, Alberto Mardegan > <ma...@users.sourceforge.net> wrote: >>> On dependencies: we are trying hard to move away from libdbus-1 and >>> libdbus-glib-1 towards GDBus. >> >> As far as libaccounts is concerned, this can be changed easily -- although I >> don't see a real benefit in moving to a slower implementation... > > What do you mean by "slower implementation"?
Well, you should know I guess. :-) http://lists.freedesktop.org/archives/dbus/2011-January/013981.html Whether we trust the test is another issue (I didn't try it myself), but anyway I don't see strong reasons for changing an existing piece of code to GDBus (of course, if we were talking about newly written code, things would be different). >>> Configuration: I don't think SQLite is at all what we want. >> >> Why not? Is it an unwanted dependency, or do you think that using it is >> overengineering? > > I just don't think it's good for storing user configuration. > Especially not on multi-user or managed- systems where it's useful > being able to configure 1000 users by dropping a simple file in /etc. I'm not sure I'm following you... If by "1000 users" you mean "1000 accounts for one user", then even in libaccounts-glib case that's just one file. If you are talking about real 1000 users, each one having some accounts, libaccounts would indeed require you to have 1000 different files -- but I don't see how this could be different for GOA: would you store the accounts of 1000 users in a single file? In any case, I fail to see the use case for it. > Not necessarily. My implementation is using the upcoming > org.freedesktop.DBus.ObjectManager so all the async issues basically > go away. See > > http://people.freedesktop.org/~david/goa-20110427/ > > for the API. OK, so getting the initial GoaClient object is an async > op (you can do it sync which is fine - it's a local RPC call that is > guaranteed to return very quickly), but from there it's smooth sailing > - you get property changes and so forth for free. Neat. I would also suggest you to do the same thing when changing the accounts: that is, instead of having an async/sync version of every _set method, just have a synchronous one which sets the value locally, and a per-account sync method (or even on the GoaClient). >> But then, how would a certain application get the title and the icon of the >> GoogleTalk service? Loading a binary plugin? > > By > > > http://people.freedesktop.org/~david/goa-20110427/gdbus-org.gnome.OnlineAccounts.Account.html#gdbus-property-org-gnome-OnlineAccounts-Account.Name > > In C, this would be > > http://people.freedesktop.org/~david/goa-20110427/GoaAccount.html#goa-account-get-name > > We could easily add support for getting the icon as well. Sure. But it beats me that we are making a D-Bus call for something that could just be obtained directly. Since this information is static, why not just read it directly from somewhere in the file system? >>> 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). > > See http://davidz25.blogspot.com/2011/04/gnome-online-accounts.html - > there's also a video of how the panel. Functionality wise -- cool! :-) Security wise not so much, even though I understand that security is not the focus of the GNOME desktop. >> Good to hear, but why not using something that is already there and offers >> more functionalities than what you propose (with extensions for providers, >> service and service-type descriptions, a mechanism of specifying default >> settings, etc.)? > > Because of the concerns I voiced in the last mail. Which I hope I addressed? I see a few issues with your implementation, which IMHO largely surpass the flaws you noticed in libaccounts-glib dependencies: - it's not yet ready :-) - it doesn't have the concept of different services on the same account (in this respect, I think that your initial proposal was more complete, because it was mentioning them) - every client needs to load all accounts data in memory, even though it might use just one account - excessive use of D-Bus, for no good reason (static information should be directly accessible) - monolithic approach to providers and services - API doesn't cover some basic use cases (for instance, enumerating all account which supports the e-mail service type) I understand that most (if not all) of these points can be addressed and fixed, or that some of them might not be a concern for the desktop computers, but it still strikes me why you want to implement a new thing when there's an alternative which also works on embedded devices. I totally understand your concerns about using the MeeGo SSO parts (though I think that even if one decides to re-implement it in plain Glib, most of the concepts are good and the client API could be quite similar to that of libsignon-glib -- though admittedly it can be done better); but for the accounts side, writing a new implementation goes beyond all logic. Well, my logic at least. :-) Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
