forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: Dispatcher 1.0 - towards a stable version
Date Fri, 05 Sep 2008 17:32:49 GMT
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.

> 
> In many cases this will mean that the dispatcher is not used and a 
> potential contributor is lost.
> 
> Performance is irrelevant if there are no users.

Agree but actually there are a couple of user, here on the list and
people that are not actively participating on this list. Feedback from
those that uses the dispatcher is that performance have to be enhanced.

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.

> 
> > 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.

e.g.
http://people.apache.org/~thorsten/droids/api/org/apache/droids/api/Droid.html

> 
> > 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. 

...
> 
> > My initial plan is to reuse the code from whiteboard/dispatcher, conduct
> > the needed changes to work with java contracts and add spring support.
> > 
> > Any thoughts.
> 
> Documentation. Documentation and, er, documentation.
> 
> Other than that go for it!
> 
> Ross

Cheers Ross for your feedback.

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Mime
View raw message