I believe the prefs format predates JSON (or at least JSON’s popularity), and changing it now is a non-starter as it would break everyone’s user preferences. Even this changeset whose only backwards incompatible changes were fixing some glaringly obvious bugs caused some reports of failing CI around the web.
We could try to migrate prefs files to a new format, but that would be a high risk/low reward operation.
Would you volunteer to respond to all the breakage reports it might cause?
I may sound bitter now, but when a maintainer says something is too hard/risky, and a random user replies with “yeah, you should do it anyway” disregarding who is it that’s going to deal with problems, it’s just utterly disrespectful.
Respect doesn’t enter into it–hell, I even agree with the assessment that the work is high-risk/low-reward…then again, I feel the proposed fix has some of the same issues. Like, the parser has worked well-enough that refactoring is maybe not a good use of time.
If the decision is made “We must refactor it”, then it makes sense to go one step further and fix the underlying file format anyways. Then again, Mozilla has a history of derping on file formats.
As for “all of the breakage reports it might cause”, given that the docs themselves discourage direct editing of files, it would seem that there probably isn’t a huge amount of breakage to be concerned about. Further, if the folks are clever enough to write a neat parser for the existing format, I’m quite sure they’re clever enough to write a tool that can correctly convert legacy config files into a new thing.
(And again, it’s common advice that there are no user-servicable parts inside good chunks of it, because it’s a derpy file format.)
Like, just to hammer this home, here is the format of a prefs.js file:
# Mozilla User Preferences
/* Do not edit this file.
*
* If you make changes to this file while the application is running,
* the changes will be overwritten when the application exits.
*
* To make a manual change to preferences, you can visit the URL about:config
*/
user_pref("accessibility.typeaheadfind.flashBar", 0);
user_pref("app.update.lastUpdateTime.addon-background-update-timer", 1520626265);
user_pref("app.update.lastUpdateTime.blocklist-background-update-timer", 1520626385);
user_pref("app.update.lastUpdateTime.browser-cleanup-thumbnails", 1520640065);
user_pref("app.update.lastUpdateTime.experiments-update-timer", 1520626145);
user_pref("app.update.lastUpdateTime.recipe-client-addon-run", 1520626025);
user_pref("app.update.lastUpdateTime.search-engine-update-timer", 1520625785);
user_pref("app.update.lastUpdateTime.telemetry_modules_ping", 1520625905);
user_pref("app.update.lastUpdateTime.xpi-signature-verification", 1520626505);
<snip>
There is no reason that this shouldn’t be in a sane file format (read: JSON). This could be accomplished with a conversion tool, and gracefully deprecated.
For the record, I agree a standard format would be better. Also for the record I’ve never even looked at the prefs code before, so my statement was coming more from experience knowing how much the tiniest changes can blow up on the scale of the web.
You never know, maybe we’ll support JSON and the legacy format at some point, but that smells like it might be unnecessary complexity to me.
You said unnecessary complexity. Normally, I’d either say that’s a good thing or suggest a simple subset if it’s something like JSON. If Firefox already supports JSON, wouldn’t there already be a component included that could be called to handle it? Is that inaccessible? Or does it suck so much it’s worth rolling and including ones’ own parser that’s not a cleaned-up, subset of JSON? Just curious given Firefox is an older, big project.
The pref parser is a small isolated module, so I don’t think it would be technically difficult to implement (bear in mind I’m not familiar with it at all).
The complexity I’m referring to was more around ux, maintenance, and support, that come with providing two different ways of doing the same thing.
““yeah, you should do it anyway” disregarding who is it that’s going to deal with problems, it’s just utterly disrespectful.”
Bringing up respect and morals when a FOSS project uses non-standard formats instead of standard ones that already existed with tooling people could’ve used? And that definitely would need extra work or fixes later? I doubt they were thinking of morality when they did it. More like “Let’s implement this feature the way I feel like doing it with my preferences and constraints right now.” Kind of a similar mindset to many people asking them for changes.
A better question would be, “Is replacing non-standard stuff in the browser with well-supported, standardized stuff worth the effort to fix the breakage?” In this case, I’m not sure without knowing more specifics. The general answer for file formats is “Yes wherever possible for interoperability and ecosystem benefits.”
non-standard formats instead of standard ones that already existed with tooling people could’ve used
That’s untrue, the grandparent comment mentions this probably predates JSON’s popularity.
Edit: Yeah, the bug itself is 17 years old, and the prefs format is probably older. Wikipedia says “Douglas Crockford originally specified the JSON format in the early 2000s;”, which means that at best the prefs format came around the same time Crockford first specified it, and at worst it probably came into being a couple eyears earlier.
Good thinking on the history. I did say “standard formats,” not JSON. Before JSON, the formats I used included LISP-style sexprs for easy parsing, Sun’s XDR, ASN.1, and XML. I also hoped simpler ones gaining popularity would lead to secure or verified implementations. That was effortless for LISP-based syntax with Galois doing a verified ASN.1 later. Most went with the overcomplicated formats or hand-rolled their own each with problems. For XML, I found I could just use a subset of it close to basic HTML tags that made it easier for someone to convert later with standard or customer tooling.
So, those were among alternative approaches back in those days that many projects were taking. Except LISP syntax which only LISPers were using. ;)
One wonders why not just, say, use JSON for this.
I believe the prefs format predates JSON (or at least JSON’s popularity), and changing it now is a non-starter as it would break everyone’s user preferences. Even this changeset whose only backwards incompatible changes were fixing some glaringly obvious bugs caused some reports of failing CI around the web.
We could try to migrate prefs files to a new format, but that would be a high risk/low reward operation.
I wish you folks would do that. :(
Would you volunteer to respond to all the breakage reports it might cause?
I may sound bitter now, but when a maintainer says something is too hard/risky, and a random user replies with “yeah, you should do it anyway” disregarding who is it that’s going to deal with problems, it’s just utterly disrespectful.
Respect doesn’t enter into it–hell, I even agree with the assessment that the work is high-risk/low-reward…then again, I feel the proposed fix has some of the same issues. Like, the parser has worked well-enough that refactoring is maybe not a good use of time.
If the decision is made “We must refactor it”, then it makes sense to go one step further and fix the underlying file format anyways. Then again, Mozilla has a history of derping on file formats.
As for “all of the breakage reports it might cause”, given that the docs themselves discourage direct editing of files, it would seem that there probably isn’t a huge amount of breakage to be concerned about. Further, if the folks are clever enough to write a neat parser for the existing format, I’m quite sure they’re clever enough to write a tool that can correctly convert legacy config files into a new thing.
(And again, it’s common advice that there are no user-servicable parts inside good chunks of it, because it’s a derpy file format.)
Like, just to hammer this home, here is the format of a
prefs.jsfile:There is no reason that this shouldn’t be in a sane file format (read: JSON). This could be accomplished with a conversion tool, and gracefully deprecated.
Edit:
It even already contains JSON!
No disrespect taken :)
For the record, I agree a standard format would be better. Also for the record I’ve never even looked at the prefs code before, so my statement was coming more from experience knowing how much the tiniest changes can blow up on the scale of the web.
You never know, maybe we’ll support JSON and the legacy format at some point, but that smells like it might be unnecessary complexity to me.
You said unnecessary complexity. Normally, I’d either say that’s a good thing or suggest a simple subset if it’s something like JSON. If Firefox already supports JSON, wouldn’t there already be a component included that could be called to handle it? Is that inaccessible? Or does it suck so much it’s worth rolling and including ones’ own parser that’s not a cleaned-up, subset of JSON? Just curious given Firefox is an older, big project.
The pref parser is a small isolated module, so I don’t think it would be technically difficult to implement (bear in mind I’m not familiar with it at all).
The complexity I’m referring to was more around ux, maintenance, and support, that come with providing two different ways of doing the same thing.
““yeah, you should do it anyway” disregarding who is it that’s going to deal with problems, it’s just utterly disrespectful.”
Bringing up respect and morals when a FOSS project uses non-standard formats instead of standard ones that already existed with tooling people could’ve used? And that definitely would need extra work or fixes later? I doubt they were thinking of morality when they did it. More like “Let’s implement this feature the way I feel like doing it with my preferences and constraints right now.” Kind of a similar mindset to many people asking them for changes.
A better question would be, “Is replacing non-standard stuff in the browser with well-supported, standardized stuff worth the effort to fix the breakage?” In this case, I’m not sure without knowing more specifics. The general answer for file formats is “Yes wherever possible for interoperability and ecosystem benefits.”
That’s untrue, the grandparent comment mentions this probably predates JSON’s popularity.
Edit: Yeah, the bug itself is 17 years old, and the prefs format is probably older. Wikipedia says “Douglas Crockford originally specified the JSON format in the early 2000s;”, which means that at best the prefs format came around the same time Crockford first specified it, and at worst it probably came into being a couple eyears earlier.
Good thinking on the history. I did say “standard formats,” not JSON. Before JSON, the formats I used included LISP-style sexprs for easy parsing, Sun’s XDR, ASN.1, and XML. I also hoped simpler ones gaining popularity would lead to secure or verified implementations. That was effortless for LISP-based syntax with Galois doing a verified ASN.1 later. Most went with the overcomplicated formats or hand-rolled their own each with problems. For XML, I found I could just use a subset of it close to basic HTML tags that made it easier for someone to convert later with standard or customer tooling.
So, those were among alternative approaches back in those days that many projects were taking. Except LISP syntax which only LISPers were using. ;)
Or Toml, since that’s Rust’s go-to data markup language.
That’d be just a little too cute.
https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences
That’s is no fun! Let us touch it!
You can edit user.js which has the same format. Modifications to prefs.js will be overwritten.
Oh right :)