On 04/27/2011 08:42 PM, David Zeuthen wrote: > 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.
I don't think that switching to GDbus would kill performances; I'm just arguing that I don't see a good reason to change some existing code to use it, since it's not better than libdbus (though it might be better from a maintainability POV). > And, btw, if you are already using libdbus-1 and/or > libdbus-glib-1 you should worry about threading instead of > performance. They are thread-safe, aren't they? > 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. OK. To have this on libaccounts-glib, you would install a file as /usr/share/accounts/services/largo-calendar.service with all the parameters/data to access the calendar. I don't think that the current implementation of libaccounts-glib supports automatically enabling newly installed services, but it something which could be added. > I don't think any client except the configuration UI is supposed to do > any set calls. It's not necessary, but it might be very convenient for applications to store some account-specific settings there. For instance, an instant messaging application might want to store the default requested presence for the account (that is, having a property "DefaultPresence" which would be set to "online", "busy", etc.). Though indeed this data might be stored somewhere else and bound to the account via the unique account ID. >> 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... I did understand how it works (or I think so :-) ), but my remark was formulated quite incorrectly, sorry. You get all accounts data with one single D-Bus call, and this includes the basic account properties, one of which is the provider name, e.g. "google". At this point, IMHO, it would be better if in order to get the Google icon (and other settings) one would read a static file, whose path is uniquely identified by the provider name, and get the information from there. While, if I understand you correctly, you would pass this information along with the accounts data, in the first D-Bus call. OK, this probably is not a performance problem in the desktop, but still it's suboptimal, at least memory-wise. >> Functionality wise -- cool! :-) >> Security wise not so much, > > Excuse me? Why exactly is this not secure? Please read the next paragraph. >> 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. Sorry, I probably should have clarified better what kind of security I'm talking about: I'm not referring to network security or even to local security threats coming from other local users. It's about trusting the applications that the user installs, and having different access rights. With this approach, we don't let applications specify their own application token, and request different authorizations to the account's data (for the OAuth case). I beg pardon -- having the word "security" associated with a certain context for 8 hours per day, I probably abused it here. But this is indeed the kind of security I had in mind, and I think you'll convene that it's not something GNOME is much concerned about. :-) > 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. Choosing libaccounts-glib would not be committing to a stable API; you can just try it out, and either propose changes or scrap it completely. >> - 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 Or "Service type". But I think this is not enough, you should at least have more interfaces on the account object, one for each scope. I mean, when the e-mail application uses the account, it also needs to know the address of the server, and a bunch of other settings. Indeed you can keep these properties on the Account interface (prefixing them?) but I feel it would be more clean to have a org.gnome.OnlineAccounts.Account.email interface (if "email" is one of the supported scopes, of course). >> - 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. >From one to a dozen, typically 5 or less. But you have quite a few settings/data on each of them (especially if you keep also static information in there), and you have multiple applications using them. I agree that no matter how many of them one has, it's not going to be an issue; but since we can easily avoid this (and without complicating things), why not do it? >> - monolithic approach to providers and services > > It's not monolithic, no. I don't know why you think it is. Well, I would expect that the Google, Facebook interfaces and those which will come in the future will be delivered as plugins. But seeing their interfaces already defined in the GOA documentation makes me think that they are not. This use case, for instance: in a user desktop, there is no support for the newly born Moogle instant messaging service. Let's suppose it's based on the XMPP protocol. 1) How would I (developer) add support for it in GOA? 2) And how would a user get my contribution? 3) And what if Moogle adds an email service later on? 4) And what if the XMPP server address changes later on? For libaccounts-glib, this would be handled this way: 1) Developing the Moogle provider and IM service: - I create a moogle.provider file, with just a couple of lines telling the name and icon - I create a moogle-im.service file, with again a basic description (name and icon might be different from the provider's -- think of Google, GoogleTalk, Picasa) and the default settings for the service: the XMPP server address, the port. Also, static information about the supported capabilities, presence states, smileys (these might actually fit better in a separate file, whose path is uniquely identified by the "moogle-im" string). - According to how the account setup works in GNOME, I either create a plugin for the accounts control panel applet or just a static file describing the UI. 2) User installation: - install a distribution package containing all the above - configure the account At this point, Empathy will simply recognize the new account and start using it. 3) Moogle email: - create a new moogle-email.service file, again with name, icon, and default settings such as address of the IMAP server, and so on - The user just installs the new file, and enables the moogle-email service in the account configuration 4) XMPP server address change: - Update the moogle-im.service file, with the new server settings. - User installs the new file; unless the server address is stored in the accounts DB (and it will not, if the Moogle account UI wisely didn't have a field for it), libaccounts-glib transparently reads the setting from the .service file. I don't see much point in continuing this discussion anyway... It's obvious that you have decided to write your own implementation, probably even before knowing about libaccounts-glib. Though I feel there's quite some NIH in this approach, I understand that unless I'm able to provide an alternative implementation of the control panel applet and a Qt-free version of the SSO, there won't be a chance to prove my proposal. And I'm certainly not blaming you for that. :-) Unfortunately though, I don't have time and energy for doing all the above in my little spare time, so I'd better shut up now and let you do your work. I'm sure I won't be disappointed from the result anyway. :-) Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
