Re: Conf: argue !

Hi

Okay, trying to incorporate the things I've read on the list so far and 
replying with this ;)

> 3. A complete path might be prefixed with (optional);
> 3.1. 'file://' => which means a file
> 3.2. 'db://' => which means the db
> 3.3. 'conf://' => a special hardcoded conf::file, necessary for essentials
> Note: this as a replacement for [scope].

Ugh, what's 3.3 for?

> 4. There is a rule for detecting a filePath in the treePath:
> 4.1. if it ends with .php or .ini or .xml => a file is requested 
> 4.2. if it starts with 'file://' => a file is requested
> 4.3. Otherwise => a domain is requested

Hm, this is strange mixing. I'd propose the following:

  - Factory defaults are always read from the module's directory in the 
repository and stored as XML. No changing here.
  - We force the user to have a binarycloud.conf.xml file that contains 
basic configuration for the framework and a Datasources.conf.xml because 
otherwise he might run into problems with getting the configuration.
  - The user might *either* store a given domain in a conf.xml file *or* 
in a database. That should stop a lot of problematic points I see with 
wild mixture.

All configuration files are stored flat in conf/ because we forbid to 
have modules with the same name as core modules in vortex. The 
configuration files have to have the same name as the modules they are 
defined in. The module name is the domain name.

- All conf/ configuration is read at system startup and cached. Same for 
the database.
- We do not support XML writing for now, so editeable stuff should go 
into the database.
- If something in the database is changed, we update this in the cache.
- We provide a phing target "clear-conf" that clears the configuration 
cache and forces the system to read the configuration anew.
- Additionally, we have a "force recompile" and "check valid cache" 
setting like smarty, so we do not have fmtime() calls in a production 
system because they are slow like hell.
- If any of the rules like "domain name equals configuration file name", 
"conf.xml and db domain" etc. are violated, we halt the whole system. 
Errorneus configuration could screw up everything.
- Every configuration domain - may it be database or conf.xml must 
provide a "for-version" property that holds the *module's* version so 
automatic update scripts are easy to provide.
- Of course we provide migration scripts when the configuration format 
changes. That is BC specific, however. Consider the next point for 
module version specific changes:
- We provide templates for configuration migration scripts. For XML we 
provide xslt templates, for the database, we provide PHP Phing Tasks 
that do SQL queries.


> 5. There is a variable 'version' which can be overloaded.
> It means: skip conf_values with version higher than "version".
> Version is initially '2.0'.

Ah, is this the same as the versioning thing I proposed above? Why is 
default 2.0?

> The new conf: Class is Singleton, and creates children, if necessary.
> The structure is such that you can't overload config_values: you must use 
> the method set(path,value).
> 6.1. A child for accessing conf::files, created only if necessary;  there 
> is a child for .php, .xml, .ini and for .db
> 6.3. A child for caching (in memory)  conf_values of a complete domain.
> 6.4. Any access to Conf: takes care for caching the complete domain 
> mentioned in the treePath (files).
> 6.5. Conf: may be 'configured' for caching: complete (db) or preLoad 
> (files).

Hm, I do not know if you meant this, but I'd say:

- Conf is a central server and delegates the reading/storing to 
ConfDriver classes, one for each data type.
- Conf cares about configuration caching and validating the cache 
depending on the settings described above.
- Conf also cares about "query caching", i.e. the tree caching. This 
does not have to go to another class IMO. It is simpler when centralized 
and objects are pretty expensive in PHP ;)

> 7. All values are stored in the db as Strings (mysql type text).
> Arrays are stored as ....... please suggest; choices:
> 7.1 valid php code
> 7.2 exported format
> 7.3 var_dumped format
> 7.4 serialized (manual doesn't like that)
> 7.5 syntax to be defined ?
> Proposal: all text in usage (a description of what the config_value is 
> for) is in english and may contain a #stringId#. This could give an admin 
> the opportunity to read these descriptions in a nice form in the original 
> language and his/her own. This to avoid sloppy translations causing 
> misunderstandings.

I'd propose the following:

- We store
   * strings as strings, fully translateable
   * booleans are stored as chars 'Y' or 'N' (fast)
   * integers are stored as integers
   * floats are stored as floats
   * no "raw" data

This way the data is completely queryable.

What did you propose for the configuration schema? I'd propose:

   domain   := (id, description)
   property := (id, path, domain, content, description)

domain::id and setting::id are primary keys, setting::id is numeric, 
domain::id is a short, english string value (max 20 chars) and the 
module name. domain::description and setting::description is a 
'#translateable string#'.

Conf would care about uniqueness of string description ids within a 
certain domain. The translation of a configuration description string 
would go into a module's translation Strings.en.xml (or later DB).

Trees are pretty sucky in SQL (because of its inferior implementation of 
the relational model). I thus agree to storing full paths and to 
extraction in PHP. We will cache all this anyway so it is not that 
expensive in production:

   /domain1/value             value
   /domain1/path/to/value     value2
   /domain1/path/to/another   foobar

Which would become:

   array(
     'value' => 'value',
     'path' => array(
       'to' => array(
         'value' => 'value2',
         'another' => 'foobar',
       ),
   )

As you can see, sections are created implicitely.

Uhm, I guess I missed most important things, but that's life ;)


Manuel