Hi, On Wed, Apr 27, 2011 at 1:16 PM, Alberto Mardegan <ma...@users.sourceforge.net> wrote: > 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).
Oh, that old thread. Well, I'll just repeat what I've always been saying: if a factor of 4 going to kill you, then you are already using D-Bus incorrectly. Either way, as I said in bug 634471 (which is where discussion of GDBus performance should take place), I'm not opposed to optimizing GDBus - I just want someone to actually benchmark things sensible instead of this completely baseless "GDBus is slow" non-sense, sorry. And, btw, if you are already using libdbus-1 and/or libdbus-glib-1 you should worry about threading instead of performance. >>>> 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. I'm talking about having 1000 Unix users on a big box (or each on separate boxes). For example, if I'm a sysadmin for the City of Largo, then it would be nice if I could just drop a file so that the "City Events" calendar account is included for each account. This is nothing new - it's what we've been doing with GConf defaults etc. forever. > >> 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). I don't think any client except the configuration UI is supposed to do any set calls. And, btw, setting a D-Bus property from a client app has no error checking (same way g_object_set() has no error checking) because the daemon-side is designed to not have writable properties. So the programmer does not have to worry about the async aspect. > 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? I don't think you understand how it works - the _only_ D-Bus call that is made is the initial GetManagedObjects() D-Bus call. Everything else is cached in each client and updated in response to PropertiesChanged signals. That's just how org.freedesktop.DBus.ObjectManager works... >>>> 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, Excuse me? Why exactly is this not secure? > even though I understand that security is not > the focus of the GNOME desktop. That's non-sense. Security is just as important in GNOME as in any other sensibly designed environment. > 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's fine, we're doing time-based releases. We also specifically don't want to commit to any stable API for a few releases. So that's why it's so much better to use something we write in GNOME itself. > - 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) It does. See http://people.freedesktop.org/~david/goa-20110427/gdbus-org.gnome.OnlineAccounts.Account.html#gdbus-property-org-gnome-OnlineAccounts-Account.SupportedSources I'm probably going to rename it "Scope" though, since it's more in line > - every client needs to load all accounts data in memory, even though it > might use just one account How many accounts do you think people have? Complaining about memory use is completely missing the point. Seriously. > - excessive use of D-Bus, for no good reason (static information should > be directly accessible) No, it's fine. You just don't seem to understand how ObjectManager works. > - monolithic approach to providers and services It's not monolithic, no. I don't know why you think it is. > - API doesn't cover some basic use cases (for instance, enumerating all > account which supports the e-mail service type) Easily added. > 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. :-) Plain GLib? Excuse me. Please realize that all the code is currently just under 7000 lines of C. Including comments and header files. That includes a gnome-control-center panel, the daemon, the client library, the OAuth2 impl using webkit and Google and Facebook implementations. It's all in one place and we are free to change a lot of things at our own pace. David _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
