On 23-Sep-06, at 8:00 PM, 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.
Not at all. I hope it never seemed that way. The DirectoryIndex thing
is a bug that must be fixed - I hope that is clear enough. It will be
fixed before 1.2, so I hope that is even clearer.
It's a bit of both. I suggest if you're modifying then first copy
somewhere else and set PluginDir to the new path, or rename the
plugin
- the names don't mean anything.
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
I could just update my code as well - I probably will - but it still
means developing in two branches for essentially the same
functionality.
To help with this what I'll do is make it easier to subclass a
plugin. This should allow you to fix some functionality in a plugin
but still benefit from updates to the core plugin. Does that sound
better than the current situation?
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
software I'm working at won't work without my modifications - and you
cannot have two uri_to_file and two serve_file plugins working as
default at the same time.
That's a small bug. I'll fix it this week.
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...
I'm a cautious person. AxKit2 is new, but is also stable (it has been
running my gallery for a few weeks now without restart). But being
new it has had some major changes and still does have some weak
areas. I'm glad you tried it, but if these weaknesses are too much
for your development to handle then you should probably go back to
AxKit1. Note though that AxKit1 is end-of-life now. There will be 1
more update to AxKit1 (to fix libxml2 support) and that will probably
be it - but lack of updates is more because it is stable, not because
we don't want to fix bugs :-)
Ultimately I think AxKit2 will be an easier deployment for your
needs,
but maybe you didn't have any issues with mod_perl that way.
I think the very hardest thing about AxKit1 was the lack of
documentation. It wasn't until I got hold of Kip's book that I
realized
the full potential - and I had been using it for a long time then. I
think the very hardest thing about AxKit2 is the lack of
documentation...
As Jörg said - please be specific about where the docs are weak as
that can be fixed fairly easily. Presumably more tutorials are
needed, but it's hard to know what people will want tutored on.
Matt.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
