Posted by Graham Leach on Thu, Oct 31, 2024 - 6:35pm --- Updated: Oct 31 '24 - 6:41pm

Hello Everyone,

In one of my many attempts to increase my facility with the family of technologies known as "CMS systems" I have run across a variety of what may be called persistent store strategies.

These strategies are designed to help in-memory systems store important information in such a way that it can be reliably reproduced despite the computer system hosting them experiencing a power outage or even planned interruption of service (migration).

Historically, the memory employed for this purpose was secondary, and the media magnetic. More lately (mostly for performance reasons) secondary storage  has evolved in the direction of various types of SRAM.

In the "Backdrop CMS" system (a fork and subsequent evolution of the "Drupal CMS" system), among the many new concepts introduced was one targeting the persistent storage of critical configuration information:  .json formatted files.

For example, the configuration file for the Backdrop CMS core language module at:

/modules/language/config/language.settings.json

Contains:

{
 "_config_name": "language.settings",
 "_config_static": true,
 "language_negotiation": [],
 "languages": []
}

JSON stands for "JavaScript Object Notation".  Literally speaking, it is a foreign concept to the back-end technology that was used to develop Drupal and its offshoots, including the "Backdrop CMS" system.  That base technology is PHP.

Since the release of PHP 4 (22 MAY 2000), a native solution has been available to any PHP developer seeking a persistent storage approach for retaining server-side configuration information:  .ini files.

https://www.php.net/manual/en/function.parse-ini-file.php

So why was .json chosen?  I am not asking this to cast doubt or aspersions on .json or even the people who chose to go with .json - I am just curious about why .json was ultimately selected as the "best" choice in the face of the other structured data notations  that were available and already present in D7 (xml also comes to mind).  

How come .json won?

I guess, ultimately, what I am looking for is a bit of a history lesson and a narrative.

g.
----

Comments

Thu, Oct 31, 2024 - 6:50pm by stpaultim

I don't know the answer to this question and was not around when these decisions were made. 

I do know that Drupal 8 was looking at using YAML files for config management and Backdrop decided to go with JSON. 

I never heard of any discussion about other alternatives, such as .ini file. 

This discussion from the Github archive MIGHT shed some light on what was being considered and why, but I've not ready through it all.

See issue #2:

https://github.com/backdrop/backdrop-issues/issues/2

I'll ask around and see if anyone has anything to add this question. 
(See also: https://forum.backdropcms.org/forum/how-does-backdrop-store-role-permiss...)

Thu, Oct 31, 2024 - 7:38pm by Graham Leach

Hello @stpaultim,

Thanks for the link.   Scanning it through, this seems like a hotly debated topic.

  • .yml files were strongly considered
    • Especially with the introduction of Symphony
  • JSON was observed to be MUCH faster than .yml
    • Like 20 to 50 times faster
  • JSON was described as being better at handle multi-byte encoded strings
    • I am not sure that .ini files can even handle UNICODE all that well.
  • From my examination of .ini file format, JSON was MAYBE seen as being better at handling more complex (i.e. n-dimensional) data representations - which Drupal is absolutely replete with - than the .ini could natively handle.  A lot of entries in the PHP .ini area have to do with making it better at handling complex data types.

Guess:  Maybe it was just a "path of least resistance" thing?  

It might just be that:

  1. .json ticked all the technical boxes (fast, UNICODE, n-dimensional)
  2. .json had already turned out to be a highly useful data transport mechanism
  3. JS was already being used extensively on the client-side
  4. REST architectures are/were highly .json friendly
  5. REST was "cool" back then, and JS/TS was on the ascendance
  6. Everyone was already messing around with JS on the front end, so familiar
  7. .json was the lowest-friction option in terms of persisting configuration data

Does anyone know different?

 

g.
----