Settings in wrong path

Bug #982699 reported by Robert Ancell
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

The settings are in /apps/onboard when they should be in /com/ubuntu/onboard:
Also, the schema name should be a domain name (I've guessed com.ubuntu.onboard, but I'm not sure what domain Onboard best associates with).


Related branches

Revision history for this message
marmuta (marmuta) wrote :

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?

Revision history for this message
desrt (desrt) wrote :

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/.

Revision history for this message
marmuta (marmuta) wrote :

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?

Revision history for this message
Robert Ancell (robert-ancell) wrote :

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 project in the future and try and use that name.

Revision history for this message
Robert Ancell (robert-ancell) wrote :

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.

Revision history for this message
marmuta (marmuta) wrote :

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?

Revision history for this message
Gerd Kohlberger (lowfi) wrote :

+1 for /org/onboard

Revision history for this message
Francesco Fumanti (frafu) wrote :

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

Revision history for this message
marmuta (marmuta) wrote :

Let's move to /org/onboard then.

Changed in onboard:
status: New → In Progress
Revision history for this message
marmuta (marmuta) wrote :

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

Changed in onboard:
status: In Progress → Fix Committed
Changed in onboard:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.