Michael Wechner wrote:
Jörn Nettingsmeier wrote:
i see. well, i see the point now, but at the same time, i don't
like to have dead or untested code in something
frankly speaking it seems to me that you call code untested just
because you don't use it and I am saying this because it seems to me
you did quite often before.
well, there is a difference between "used to work with some local
modifications in the jolly old days of lenya 1.2" and "gets constant
testing and review during the 1.4 release process".
if anyone here is using caching in 1.4, please speak up, and do share
your experience with us.
But I made my arguments why I think this code helps and if others
don't feel the same, then I guess you are right to remove it, but
please don't mix up words such as "dead" or "untested" just because
the code might have gotten to a point where it's unncessary to modify
it every day.
caching and cache invalidation is probably the single most hairy issue
in computing. don't tell me you honestly believe that since it used to
work way back when, it is still going to work without the need for
testing and quality assurance after all those fundamental changes in
trunk. if we care about this feature, every developer should be using it
by default.
just take the proxying problem that has surfaced only weeks ago. an
absolutely crucial feature that just stayed below our radar too long.
and it's quite an embarassing bug so close to a release.
imnsho stuff in the default publication's sitemap should be maintained.
if it is not being maintained, i'd rather remove it than to annoy users
with promises of stuff we can't really do.
in order to make sure that this stuff gets constant testing, it should
not be disabled by default in a development tree.
same goes for the XUL-based gui. who is testing that?
There are many libs which do what they are supposed to do and that's
it. But nevertheless they are very helpful.
libs are self-contained, with a clearly defined API.
the caching stuff is hacked into an example publication sitemap.
there are next to no comments, and it is not obvious to me how the stuff
is supposed to work.
the most glaring issue is that using the (untested) XUL interface is
mutually exclusive with using the (untested) cache. don't tell me this
makes sense and used to work in the old days. it's a fuck-up.
and it is caused by deactivated and untested code in trunk. if somebody
takes an interest in it, great, we should keep it by all means. but if
it's just rotting there, why bother?
depending on the answers to a) through c), there's question
d) can we just chuck this out?
with the current performance issues I would rather leave it as a
very reliable alternative.
fine with me, if anyone can confirm it works for them and add some
documentation.
hmm. i would agree in general, but i haven't had any problems with
live site performance. anyone?
I think it's rather slow compared with other systems I know.
mod_cache should be able to deal with that.
Have you actually tried mod_cache within a productive environment?
IIRC we had some difficulties re invalidation, etc, but maybe we were
just too stupid and any pointers how to do better with mod_cache is
very much appreciated.
hmm. i have not yet used it to cache lenya, but it worked quite well for
php-based stuff i did. but i'm about to set it up - will keep you posted.
for now, i would like to comment out all cache-related stuff in the
sitemap (not just doctor the match pattern) and add all the
information people have provided in this thread as comments. wdyt?
yes, it definitely makes sense to add some comments and
clarifications.
will do.
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
