Tag Archives: ubuntu online accounts

A number of Geary bounties have popped up in recent weeks that our users may want to know about. Bounties represent reward money for coder(s) who successfully land their improvements in the program. (Yorba created a bounty a few months back for Geary, you can read about it here.) Some of the new Geary bounties include:

“Notify of new messages at startup” – This is a long-standing feature request and it would be great to get this landed in Geary. There’s a number of fancy ways this could be achieved, but I think the easiest way to approach this would be for Geary to be launched at login time with a magic command-line option that hides the main window. As new messages come in, notifications are displayed. If the user clicks on the Geary icon or the notification bubble, the hidden window is displayed. The added complication here is that closing the window should merely hide it, while the Quit option would, in fact, cause Geary to exit.

“Ubuntu online accounts integration” – The basic thrust of this problem is to fetch account information from UOA and start pulling down mail with no user interaction (other than starting Geary, of course).

With all bounties, please be sure to read over the linked Bugzilla ticket and understand all the in’s and out’s of the task. Tickets are also the best place to ask questions for the Geary team. We’re here to help!

Some of these bounties are courtesy our good friends at elementary while some have been initiated by independent users who simply would like to see Geary improved. Follow the above links to see how much money is up for grabs on each.

If you see a feature you really, really want to see added to Geary, consider how much it’s worth to you and pledge that amount. High dollar values encourage attention from developers and gets traction and movement. And if one of the above doesn’t tickle your fancy, there’s a whole host of other outstanding bugs that are listed but have no money behind them; pledge and get them started!

As always, Yorba developers will not collect bounties, but we certainly encourage everyone out there to think about (and act upon!) how they can contribute toward improvements.

A software developer decides to write an open-source GNOME desktop application that interacts with any number of Internet services, such as Facebook, Gmail, Flickr, and so forth. It’s not specific to any one service, however. The app should take advantage of all the available desktop technologies, not only to leverage all that hard work, but also to be a good desktop citizen.

The first thing the application does is log in to an Internet service. What should this developer do?

(a) Handroll the authentication code. Most Internet services use a token-exchange system, but each service is different, so the developer will need to write custom code for all of them. The user will want the application to save the password for next time, so better look into keyring solutions. And there’s always the problem of where and how to store long-term tokens, since every service has its own Terms of Agreement. And don’t forget to request Application Keys — each service has its own. Some services have different entry points for their various “faces” (i.e. Yahoo! and Flickr) while some have a federated login system (i.e. Google).

Halfway through the process the developer thinks, “Why am I reinventing this wheel? A lot of applications could use this code.”

Or (b) Use a system library. The developer calls the library and gets back a token. No messing around with passwords, keyrings, confirmation Web pages … all that’s handled by the system service.

The developer thinks, “Perfect! Problem solved and we’re being a good desktop citizen because the user only has to enter their password once.”

This is a poisonous situation for application developers. It’s not terribly visionary of me to suggest that the number of programs that interact with Internet services — the magical “cloud” — is only going to grow over time. GNOME and Ubuntu are both acutely interested in attracting more developers (or at least should be). But new and curious developers arrive and are confronted with this situation.

I speak from experience. Both Shotwell and Geary could use some kind of Online Account solution today. Canonical has forked Shotwell to call UOA rather than our handrolled code, but those patches have not migrated upstream, nor could we take them as-is. Requiring UOA would preclude Shotwell from running on non-Ubunten distros.

I’m not here to argue UOA vs. GOA, or GNOME Shell vs. Unity, or lament that there’s yet-another split on the desktop. I accept that both sides have decided to go their own ways (here’s Debarshi Ray giving his reasons). But we at Yorba want Shotwell and Geary to work well — no, work spectacularly — on all GNOME desktops. That we can’t deal fluidly with something as low-level as server credentials seems absurd.

I once had a professor tell me, “All problems in computer science are solved with a layer of indirection.” He was being snarky, but there’s a germ of wisdom in that observation. It seems to me that the solution to the GOA/UOA divide could be solved with a translation or wrapper library. I’m not thrilled about wrapper code, but sometimes that’s what you’ve got to use.

To throw the first dart at the dartboard, here’s my proposed interface for such a library:

Enumerate supported Internet services: Facebook, Yahoo!, Google, etc.

Query a particular service for details/capabilities/description/icon/etc.

Generate an authentication token for a particular service

Launch the login/account registration application (i.e. the GOA/UOA program that takes the user though the steps of logging in to a service and making it available to all applications)

Obviously it’s far more complicated than this, but that’s the gist. I know GOA is DBus-based, and I believe UOA is as well, so the solution could simply be a DBus interface that both technologies implement, perhaps in the org.freedesktop namespace. In fact, maybe this should be a freedesktop.org initiative.

We need something. Asking an application developer (including Yorba) to pick UOA or GOA is a non-starter. There seems to be a bit of bad blood between the GOA and UOA camps — I don’t know all the details — but I ask both of you to scratch together a bridge rather than fork the path.