forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] structurer location and resource types
Date Fri, 24 Mar 2006 14:25:35 GMT
Thorsten Scherler wrote:
> El vie, 24-03-2006 a las 22:11 +1100, David Crossley escribió:
>>Please don't take my comments below the wrong way.
>>I seek the best for the project.
>>I know that this is a Random Thought thread but
>>there seem to be some design and direction things
>>which should break out into separate discussions.
>>Thorsten Scherler wrote:
>>>Ross Gardler escribi??:
>>>>Thorsten Scherler wrote:
>>>>>Thorsten Scherler escribi??:


> The dispatcher can be used and since 2 month we could have released the
> dispatcher from the whiteboard (but I reckon if I am not starting this,
> the dispatcher will remain forever in the whiteboard - no offense).

Then put it to the vote, nobody is blocking this move. In fact I (and 
possibly others) have suggested it many times, each time it is *you* 
that has blocked becuase you wanted to complete "this" or "that" first - 
it is all in the archives.

> BTW we did not even start talking about releasing 0.8.

We have outlined (and agreed) what needs to be completed. There is a 
Jira roadmap for it.

>>>That leads to the need to extract as well the lm from forrest core and
>>>to make it to a component on its own (maybe to store the lm in a plugin
>>>makes the most sense).
>>Or perhaps a Cocoon block that we maintain.
> good as gold
> +1

Yes, a Cocoon block would be great. Daisy recently started using the 
locationmap in an extension to their CMS. If we make the LM a block then 
it is possible the Daisy devs (and others?) will start using it more and 
contributing to the code.

>>>Actually I am thinking it would make sense to make the dispatcher a
>>>project on its own and support different frameworks, like e.g. Struts.
>>>Maybe starting as the first forrest subproject which offers different
>>>contracts/structurer for e.g. Lenya, forrest, cocoon, struts, ... as
>>>plugins, modules, ....
>>I don't think that this project is big enough
>>to support sub-projects. We are barely a functioning
>>community at the moment. The number of truly active
>>developers is very small.
> Yes and I wish that our who.html would reflect the reality of active
> committer and not listing people as active that have not done a single
> commit/mail since years.

You are a committer, you know what to do. Of course, I should also lend 
a hand, as should everyone else, but we all do what we can and nobody 
else is airing this complaint. The buck stops with you I'm afraid.

> Anyway, the reality in this project is that the dispatcher has become a
> subproject of forrest. Further the dispatcher does not focus to support
> forrest only, I reviewed the dispatcher code and testing ATM to use it
> in the cocoon samples and it works quite nicely. 

I do not want to comment on this without understanding exactly what you 
mean by "a subproject", can you write a proposal covering design, 
benefits to the Forrest project and community and benefits to the ASF?

Don't assume these things are obvious. They are not to most of us, at 
least to me.

As  project we do not have any guidelines for proposing subprojects. 
Perhaps we can use the incubator model for proposals. This way, if 
Forrest does not feel it is the right thing to do you will be well on 
your way to creating a proposal for the incubator, you can use this 
initial draft to find a mentor and a champion.


I am not suggesting that I support the idea of a subproject or incubator 
project. I'm saying I do not understand why you think this is a benefit 
to everyone, without that understanding I can have no opinion.


>>I know we said that for the upcoming 0.8 release
>>that skins will still be the default. Is that what
>>you are referring to?
> I think many committers/dev/user are more committed to skins then to the
> dispatcher and this can be seen in the mail archives. That is perfectly
> ok, if those committers are willing to support skins in the future.

Committers - this is simply not true. There are three active committers 
working on the Dispatcher and the rest of us have provided oversight, 
feedback and comment.

Devs - again not true, our most active dev (not currently a committer) 
spends lots of time trying to understand the dispatcher

Most active devs have creat at least one sites using views, then V2 then 
V3 in order to be able to provide feedback to you with respect to your 
approaches. This really should be enough for any Open Source Community.

Speaking as a commercial user of Forrest (not someone who is here for 
fun, at least not all the time), I cannot adopt the dispatcher in client 
sites since it will increase the costs of their projects. I *want* to, 
there are features I really need, but I cannot, it is simply not a good 
business decision at this time (see below).

Users - true, speaking purely for myself as a user ...

I am currently more committed to skins because the few sites I have 
using the dispatcher take up far too many person hours to maintain. This 
is because of a lack of design in the original code, resulting in 
numerous versions of the code base. This is made worse by a lack of 
backward compatability between each "minor" change.

Sure, they are whiteboard components and to an extent this is to be 
expected, but only devs will put up with this. Until backward 
compatability exists do not expect users to adopt code.

In summary, please remember that we all have different motives for being 
here. Perhaps your proposal for a subproject can address some of the 
advantages to different types of users.


View raw message