Re: lang and conf synthesis

alex black wrote:
>> Can you explain how caching php files can work then, and when the 
>> string replacement should occur ?
> 
> 
> I wouldn't cache PHP files at all except for the normal bytecode caches 
> liker turckMM. Instead I would focus on caching _output_ automatically 
> all over the place.
> 
> Use smarty to check if a page render is even necessary, after a bit of 
> use on the server - it won't be. At the very least a whole chunk of the 
> page can be cached and that saves all those string lookups.

For a dynamic site (where actions will have to be made for each request) 
this means that on each page we'll have from dozens to hundred of 
queries to read strings. Far from efficient probably. In my opinion it's 
wasting server resources. Why read the strings on each page generation 
while strings will change very slowly ?

When we envisaged droping phing, I was told caching would replace 
phinging for strings and that no overhead was to be expected. If there's 
no caching for php+strings replaced we'll loose a big advantage of bc imo.
Reading confs from db is a load for the server already, why add strings?

Said differently: currently phing is doing this: it takes a source php 
file and builds a 'cached' php repository that is runned. This is not 
easy for the developper, that's why we wish to drop phing step. But 
where is the problem if this step is hidden and short? Most of times 
when coding we changes three or four files, then run. Only few files 
will have to be reparsed & recached, it'll be far more faster than phing 
now, but once cached the overhead will be only the line of test:
     if mtime(phpfile) <= mtime(cached-php-file)
which is not heavy.
So why don't you want to have php files built at runtime wheread you 
were ok when they were built by phing ?
-- 
Jean-Christophe Michel