58816 - No convention for creation of 3rd party prefs

Status: RESOLVED FIXED

(Developer Documentation Graveyard :: General, defect, P3)

Description

[Eric Hodel]

A documented convention needs to be established for the creation of third party
prefs.  Currently according to dveditz (IRC) there is no convention for these
prefs.  I don't wish to pollute the prefs namespace by arbitrarily defining my
own pref that may in the future be overwritten by a different mozilla developer.

I plan to the following scheme for prefs for my mozilla projects:
pref("3rdparty.segment7_net.drbrain.project.projectpref", "prefdata");

"3rdpary" is be the root of the prefs hierarchy for non-Mozilla projects.

"segment7_net" is be the domain of the email address of the developer with the
period ('.') characters changed to underscore ('_') characters.  Unfortunately
this does not prevent confusion among domains that contain an underscore in the
name.

"drbrain" is the email address of the developer on the list domain.  Underscore
characters would replace all period characters in the email address.  Again this
does not prevent confusion among email addresses that contain an underscore in
the name.

"project" would be the name of the project as defined in the
manifest.rdf/contents.rdf file.  All whitespace must be removed from the name.

"projectpref" is the pref for the project.  There could be a hierarchy of
"projectpref" values.  This would mirror browser.*, history.* ...

"prefdata" would be data for the pref.

Comment 1

[Dawn Endico]

drbrain offereed to write up documentation for his proposal. The proposal
needs to be reviewed and approved first though. Assigning to Dan since
this is his area and cc'ing others who may be interested.

Comment 2

[Eric Hodel]

After thinking about the problem of using _ in the prefs I decided that it would
probably be better form to use either the URL scheme of %20, etc to represent
spaces and other strings than using _, or using HTML/XML escape sequences of
&#<character code>;  This would remove the problem of ambiguity between the
actual undescore character and the underscore being used to represent a space.  

Comment 3

[James Cox]

accepting QA for mozilla developer docs.

some of these bugs have been around for a _long_ time. Reporters, would you
please review the bugs, see if the issues have been resolved, and close bugs
appropriately.

I will do a full review of all bugs not touched in one week (8th April). 

Thanks.

</spam>

Comment 4

[Daniel Wang]

I just did a draft on preference design spec (bug 158384 attachment 121908 [details]). Please
review and comment

btw, '3rdpary' cannot work because it begins w/ a number.

Comment 5

[Ben Bucksch (:BenB)]

> pref("3rdparty.segment7_net.drbrain.project.projectpref", "prefdata");

Isn't that overengineered? How about 3rdparty.net.segment7. ... and the stuff
below that is up to the owner of the domain? That's almost like Java's name
spaces work.

Comment 6

[Gervase Markham [:gerv]]

The reason Java has a mechanism similar to this is that there's no way for all
the Java developers in the world to coordinate to minimise namespace clashes.
That really isn't true for Mozilla - a central pref name registry is a sensible
project, and could be the input into the various pref editors that are out there.

If you are creating a new pref to do with http, it's much more sensible to have
it under networking.http than 3rdparty.net.gerv.gerv.http. A registry (or just
ignoring the problem, as we have been doing, which hasn't caused any clashes I
know of) would achieve that.

Gerv

Comment 7

[Nickolay_Ponomarev]

FWIW, currently extensions use <extension name>.pref or extensions.<name>.pref naming scheme.

Comment 8

[John Karahalis [:openjck]]

Automatically closing all bugs that have not been updated in a while. Please reopen if this is still important to you and has not yet been corrected.

Comment 9

[John Karahalis [:openjck]]

Reopening for review by Sheppy.

Comment 10

[Eric Shepherd [:sheppy]]

This has been documented for some time:

https://developer.mozilla.org/en-US/docs/XUL/School_tutorial/Handling_Preferences#Adding_preferences_to_an_extension

https://developer.mozilla.org/en-US/docs/Adding_preferences_to_an_extension#Establish_the_defaults