Re: Conf: argue !

>>> How ? I'd propose to use a var_dump of all confs and simply include 
>>> this php file. It would be regenerated on each change in confadmin.
>>
>>
>> Yes, this is what I meant, but I'd use serialize(). However, things 
>> could be changed through some sqlite tool and you'd have to check for 
>> that kind of changes.
> 
> 
> Why do you think serialize is better ? isn't it slower to read 
> serialized arrays than to parse a php file?

var_dump does not create the right output and i do not know how buggy 
value_dump is right now.

>> Extra caching options don't hurt: In development, you read 
>> configuration every time and in production, you have full caching.
> 
> 
> Excaty, so i wonder when these extra caching options will be useful :p
> dev time: reload always; prod: never reload;

Okay, so two settings only.

>>>> - 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.
>>>
>>>
>>> Simpler = no valid cache testing at all, simply regenerate the cache 
>>> when data changed or when a reload-from-xml action is done.
>>
>>
>> Hard to do if people change things with another database tool or edit 
>> the XML configuration.
> 
> 
> Are you telling reading mtime of files is slow?

yes, file statistic functions are very slow.

> Why is it hard to select all conf and write it down as php? (same with 
> xml by the way, since we need to handle precedence of custom over 
> default values). And using Creole could do it with other dbs, isn't it?

Ah, the point is that if people could change things with phpMyAdmin or 
such in a live system and not through the web. But of course we could do 
"do caching" in production with a nice "flush config case" button 
somewhere on an admin page.

>> Yes, but this happens before caching, so people cannot even create 
>> invalid configuration with real DB access.
> 
> 
> I mean that we can check bad names in conf when rebuilding the cache.
> No need to wait for running the site.

Yes, it should be enforced at both points.

>>>> 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
>>>
>>>
>>> Ah. But how to use path with constants like BC_BASE_URL without raw 
>>> type?
>>
>>
>> Good point. We could make configuration values "translateable" and 
>> support @TOKEN@ style tokens.
> 
> 
> Very complex imo. And we won't be able to use conf for translation, 
> since translation must work before conf is parsed ;p
> Raw is good, or we need to add a simple way to tell "replace this php 
> constant by its value at runtime".

Okay, so we allow this, too. Then, we'd have to tag this somehow. 
Additional field?


>>> property::path should already be unique. Of course this makes a long 
>>> pkey, but since all db is cached into a php array, why have a numeric 
>>> id?
>>
>>
>> Because you might decide to shift things and path is volatile in this 
>> respect. However, you are right, id is a candidate key - a *possible* 
>> key.
> 
> 
> Right, but there's no relation (nowhere referencing this path in other 
> confs) so changing path doesn't hurt anything.

Okay.


Manuel