If we really want to attempt to push a release and merge this weekend, can I suggest that we table this issue for this release, have David back the related change out of his branch, and we'll discuss it more for a later release?
I see your point Veikko - but again, TTLs, turning off mtime checks, etc.. these are all hacks in my opinion. This is where my issue lies. If you can't distribute compiled configs, and you don't want to require phing, how about we rid ourselves of ini files completely and go for php-based configs? Easy to edit, no caching required... We discussed this way back when ;) Anyway.. I'd still like to proceed, and it sounds like I've been delegated to actually do the merge and make it happen. Would you guys give me one last email and let me know that your branches are ready? (David: of course after you've backed out the cache change) Thanks! --Bob On 11/24/05, David Zülke <[EMAIL PROTECTED]> wrote: > I don't get the purpose of a TTL. If the filemtime of the original version > is newer than the cached version, we re-generate the file. Why do you need > an TTL there? > > - David > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Veikko Mäkinen > > Sent: Thursday, November 24, 2005 9:06 PM > > To: Agavi Development > > Subject: Re: [agavi-dev] Re: The merging-my-branch discussion > > > > David Zülke kirjoitti: > > > My thoughts exactly. Either my clients are dumb or don't care, and let > > me do > > > the stuff, or they are smart and fumble around with their system. If the > > > latter is the case, they can just as well install Phing. I really find > > the > > > concept very, very appealing. > > > > > > > You have to think about "clients" little more widely. I consider all > > users - both developers and end users that use some application > > developed on top of Agavi - our "clients". Let's take for example some > > killer forum (killer as in killer application, not a forum for killers) > > web application (isn't web forums what PHP is designed anyway :) The > > application must work almost-out-off-to-box. Debug cannot be on but > > requiring Phing just to get some other application installed would > > definitely be an overkill. This could of course be solved by setting > > debug on, running once and then setting debug back to false... but, like > > bob said, this is kludgy. So the way Agavi cache now works would suit > > perfectly. > > > > I think having an Phing task to build cache file and disabling mod time > > checks is a Great idea, but we must not take away the current > > options/behaviour. And again, TTL-setting should be taken into a > > consideration now too (even if we decide to implement it later or not at > > all). > > > > > > -veikko > > > > P.S. I promised David that my branch is ready for merging this saturday > > night (GMT). The merging, however, is going to be nasty because there > > are so many conflicts. I'm going to need help with it as I have never > > done it before. > > _______________________________________________ > > agavi-dev mailing list > > [email protected] > > http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev > > > > _______________________________________________ > agavi-dev mailing list > [email protected] > http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev > _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
