A few months ago, after talking about this for a while, I finally did a git migration of various XDG specifications (autostart, basedir, desktop-entry, menu and systemtray). It was a test migration, so I only published this in a personal repository on freedesktop.org. And I quickly became busy with other things.

I finally pushed this repository to xdg/xdg-specs on Thursday. It's a shame it took so long, especially since some people were waiting for it. But it's done. So what's next? I'll see if we can import a few more specifications in there, but I'll also look at improving the website, and how it's generated. It might make sense to re-use what was done for library.gnome.org here.

Oh, and it's also a good opportunity to start fixing some long-standing issues with some specifications :-) I have some list of improvements I'd like to see, but do not hesitate to share some of the annoyances you experience with the specifications!

It looks like I succeeded in never promoting cups-pk-helper... Let me try to fix this so that more distributions start to look at it :-)

One year and a half ago, for openSUSE 11.1, we wanted to make it easy to configure printers. So naturally, we integrated system-config-printer since it works well, is well-maintained, and is adopted by other distributions. However, the security team didn't want to make the default cups configuration too permissive (for good reasons), and it resulted in lots of root password prompts by default, which is not so cool for end-users. And we thought: So if we don't want to make the whole cups configuration permissive, maybe we could have a mechanism to have fine-grained privileges... There's this cool little project called PolicyKit that could help. This is how cups-pk-helper was born.

We could of course have tried to push this solution in cups itself, and to be honest, this is what would make most sense. However it would have required much more effort: nobody wants a patch that wouldn't get accepted by the cups team, and the cups team would certainly require this feature to work in a way that would make it implementable on other operating systems. And I didn't feel ready for such a battle.

So I went ahead with the small helper, and after a few hours of hacking in September 2008, there was already some working code and a patch to make system-config-printer use this. A few bugs later, it all went in openSUSE. At some point, Tim Waugh accepted the system-config-printer and Fedora also started using cups-pk-helper. This is also when Marek Kasik started working on cups-pk-helper, implementing some additional features.

Fast-forward to today. I've just released cups-pk-helper 0.1.0, and I'm hopeful that the code will move to git.freedesktop.org really soon now.

So what kind of fine-grained privileges do we offer? There are actions for editing local printers, remote printers, classes, jobs you own, or jobs you don't own, as well as simpler actions like the one to enable a printer (something you might want to allow without allowing the edition of a printer), or a low-level action that can be used to upload/download a file to/from the cups configuration. We're trying to be relatively flexible, while still limiting the actions to what we believe is really useful. What we have right now looks relatively reasonable, but it's certainly also wrong in some ways. We just need feedback to know how it's wrong ;-)

To make it easy to integrate cups-pk-helper in system-config-printer, the D-Bus API is based to a large extent on the pycups one. The good news is that the API makes sense, so it's no big deal; but we could possibly diverge a bit if needed. So if you're working on another tool to configure printers, don't hesitate to look at the D-Bus API and send comments on what is missing there for you.

Oh, and of course, in openSUSE, we still require the root password for all those fine-grained privileges, but at least this is easily configurable now :-)