Settings in wrong path

Thanks for the suggestion and the work you put into the patch, it's very much appreciated. We're discussing this change. Do you perhaps have any other links?
Moving natilus to org/gnome/* seems to make sense since it is a gnome application. The new unstable docs for GSettings discourage "apps", but I'm not sure if this has to be interpreted as a must do. Do you know the rational behind this change? Where do I have to look for the wiki page the linked post mentions?

The schema name should absolutely be a domain name -- there is no convention for doing other than that.

The confusion about the path names stems from my failure to establish a convention early on -- but since more than a year ago, it's been very clear that the convention should be to use paths based on domain names, as Robert suggests. The schema compiler will even throw warnings now if you use paths like /apps/.

Thanks for the clarification. Could you explain the rational behind this convention? Is there an old discussion somewhere?
The change may have been clear for insiders, but it hasn't trickled down to Ubuntu's devhelp documentation and schema compiler yet.

There is consensus amongst us, that /com/ubuntu/onboard is not an appropriate path for upstream Onboard. One suggestion was /org/onboard, similar to gwibbler. Does that fit the convention?

Personally, I liked "apps". I fear, that without it, applications get lost in arbitrary sub-trees - hard to find, hard to remember.
If we're talking about internet domain names, is it wise to use them for local storage? What is to happen when a project's home page changes?

I'll leave it to Ryan to confirm but I believe the primary reasoning for using the domain names is to avoid any collisions in the settings database (dconf in the normal case). In the case of /apps/onboard you are potentially at risk of another application called onboard using this name and colliding with your settings. If you use a domain name that you own, then the chances of collision are low. You probably can do what Gwibber has done an pick a domain name that would be appropriate for your project, but if you don't actually own that domain then there is some (incredibly low) risk that someone could register onboard.org project in the future and try and use that name.

Or to put it another way, keys are stored in the form vendor/project where vendor happens to be in domain name format (as that is an easy way of ensuring vendor names don't clash). Note that for normal usage your application doesn't actually access the keys by path name - you access them by schema name. So the paths are really only applicable when using a debugging tool like dconf-editor.

Thanks, that helps. Seeing it from dconf's perspective, that makes sense. Still, I can't stop myself thinking how frequent name collisions really are, and if there aren't alternative ways to avoid them, perhaps without throwing out all of the structure. Encouraging vendor sub-domains in apps, e.g. /apps/gnome/, /apps/ubuntu/, comes to mind. Projects without vendors would still be tolerated to stay in apps until a collision forced them to move.

The difficulty for Onboard is that there is neither vendor nor dedicated (internet) domain name (owned by us) and I can't tell if there will be either in the future. For now we're just a bunch of volunteers and we'd have to make both up out of thin air. Hence perhaps "/org/onboard". If someone registered that domain _and_ installed a colliding schema, we'd have to work it out or possibly move - like we have to right now...

Ryan, is this acceptable for you too? Francesco, Gerd for you?

Paths and schema names may be different entities, but aren't they both in danger of collisions? Would it really help to keep them not in sync?

+1 for /org/onboard

According to what I know about it so far, /org/onboard seems the best choice also for me.

Let's move to /org/onboard then.

Fixed in trunk, rev. 820, the migration could use more testing though. There is supposed to be no noticeable change after upgrading. If settings are lost please let me know.

There is debug output available with
$ onboard -dinfo

and the migration can be repeated after
$ gsettings reset-recursively org.onboard