Thorsten Scherler wrote:
On Fri, 2008-09-05 at 14:51 +0100, Ross Gardler wrote:
Thorsten Scherler wrote:
Hi all,
I will have some time in the next week to enhance the performance of the
dispatcher. The performance always have been the Achilles’ heel of the
dispatcher.
Actually, the achilles' heel is the lack of clarity in the documentation.
This mail is an amazing coincidence. One of our team hear asked me this
morning how to do something with the dispatcher. I've done it before and
have sites running dispatcher, but I can't remember how I did it and I
can't point to any documentation about it.
How about
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/
I agree that documentation always can be enhanced but we have some.
I didn't say there was no documentation I said there was a documentation
problem.
Pointing to a resource that is unintelligible does not help.
I've read those docs, even written some of them, but they make little
sense to me and I have the background of Forrest. The individual I'm
talking about has also read them and failed to achieve what he needs.
(and yes I have directed him to the lists - he'll turn up soon I'm sure
- but this is a low priority project for us so time is not on our side)
...
I totally agree that the next version should be documented in more
detail. I promise I will write as much javadocs as possible and we
should review above linked documentation and see how we can be more
clear about it.
Excellent - thank you.
Of course, I should help myself, but I don't have the time. I only
mention it because you asked for opinion.
Another week point was/is the readability of the code.
Indeed, this is part of the documentation.
Yes, I agree. I found a nice tool to create uml diagrams in javadocs:
UmlGraph. Have a look at the droids javadoc to see it in action.
What about the horrible mess of redirection (indirection) between
sitemap and locationmap. I've found it near to impossible to figure out
what is coming from where in the dipatcher.
I'm sure it doesn't need to be as complex as it is, but I can't figure
out how to simplify it.
Perhaps an effort to document the flow will help make it understandable
or illustrate where we can simplify.
Again, I doubt I'm going to be able to do this myself, I'm just flagging
areas for improvement - sine you ask ;-)
e.g.
http://people.apache.org/~thorsten/droids/api/org/apache/droids/api/Droid.html
I'll have to take a look at UMLGraph - thanks.
Another thing that I always wanted to integrate are java based
contracts. I want to allow within the next version of the dispatcher
that one can use a class instead of a xsl.
How about we finish one feature before adding another?
Which feature is unfinished? I have more or less a week for the rewrite
and yes I will first concentrate on implementing everything we have till
now in a clean efficient way and then if time allows at the java
contract support.
Dispathcer.
It's still in whiteboard , therefore it is unfinished.
I'm just saying we should get a usable version out there that people can
use (normal people, not just those with years of Forrest history) and
then start adding new features.
Cheers Ross for your feedback.
You're welcome. I know your big enough to pick and choose the most
important bits, rather than think I'm demanding the world (although if
you want to deliver the world...)
Ross
