On Sunday, 24. September 2006 02:00, Lars Skjærlund wrote: > > Nothing "cannot be solved" - it's just software, and it seems you've > > uncovered a bug in uri_to_file that needs fixed anyway. > > What I meant with "cannot be solved" was that it appeared that you did > not want to solve it.
While I don't exactly recall the issue you mention, be aware that we don't ignore your feedback. IIRC, Matt explicitly said that we should modify uri_to_file to follow Apache's behaviour. It was just not done yet, since like most open source projects, it is done in spare time. > I'm fully aware of that. However, following this advice would mean that > next time you update some central parts of Ax2, me as well as my users > would miss that update as we're using the non-default plugin. Of course The idea is that plugins are small enough so that it won't hurt you if you use different/older code: For example, server_file works as intended -- it could happen that it is never touched again. If you modify it, you will get a modification of a working plugin. Should we ever update serve_file, you will still have a stable and working plugin. Your site won't break, and if your custom serve_file fulfilled all your needs, it will continue to do so. Of course, should we use your feedback to add functionality you added yourself, you could switch over. But since you were working off a stable version, there is no pressing need. > And the changed line? I tried setting the last modified header in my > plugin, however, serve_file insisted on loading the mtime from the temp > file and overwrite the value I supplied. The result beeing, of course, > that browsers would reload the pictures all the time as the temp file > would always have a new mtime. > > I also gave up asking you to change it as I expected an answer along > the lines that 'AxKit performs so well that you don't need caching'. Oh come on. You're being unfair. Your expected answer has nothing to do with your problem. I'm quite interested in what you did, maybe the patch is generic enough to be included in the next version? > When I replace modules like uri_to_file and serve_file, I think I > replace so central parts of AxKit that I may be starting a new > development branch - and I don't want that to happen. However, the VDMS As Matt already said, some changes are in fact bug fixes. Send a patch and we will consider it for inclusion. Others are specific to your needs, but as shown above, it doesn't mean you are bad off by forking. > > You're being a big help in finding the areas of weakness of AxKit2, > > but you have to weigh that against the fact that you're not playing - > > you're trying to build something real. > > Is that to be understood like AxKit2 is simply a playground to try new > ideas? Whilst I respect that, it's definately not what I need right > now... It means that AxKit2 is still very young. It has a solid base, but only real-world projects can help smooth out rough edges. Our intention is to have a good Perl/XML application server that can compete with Apache/mod_perl. > I think the very hardest thing about AxKit2 is the lack of > documentation... Where exactly? What questions did occur to you, and where did you look for answers? IMHO, AxKit2 is well documented for plugin authors, it has a number of working examples, it's just not a book. Let us know what problems you encountered, then we can fix it. -- CU Joerg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
