Re: Conf: argue !

guys -

these suggestions all needs to be integrated into a revised conf 
proposal draft on the wiki - once we have all the points in front of us 
in a draft we agree on, each of the points should be put in a ticket, 
then we can get to hacking.

_a





On Feb 24, 2005, at 10:35 AM, Manuel Holtgrewe wrote:

>>>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe-zNu2Yekbks92Brm55YPRC3dfcadvtA/[email protected]
> For additional commands, e-mail: dev-help-zNu2Yekbks92Brm55YPRC3dfcadvtA/[email protected]
>
>

-- 
alex black, founder
the turing studio, inc.

510.666.0074
[email protected]
http://www.turingstudio.com

2600 10th street, suite 635
berkeley, ca 94710