----- Original Message -----
From: "Thorsten Scherler" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, March 24, 2006 9:00 PM
Subject: Re: [RT] structurer location and resource types
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??:
> >
> > ...
> >
> > > IMO this internal structurer definition do not belong into the
> > > {xdocs}
> > > dir.
> > >
> > > Resource types specific structurer have to be stored in a different
> > > folder then the xdocs dir as well.
> > >
> > > IMO it makes sense to move them out of the xdocs dir and have
> > > something
> > > like
> > > structurer/
> > > |-- internal
> > > |-- resource-types
> > > `-- url
> >
> > Can the location be defined in either a property or the locationmap?
> > The
> > user should be able to specify these locations.
>
> Well, yes, since this location are *additions* to the current locations
> of the lm the user can override it on a project base. I do not find
> time
> to implement the forrest.properties.xml in the dispatcher ATM (and not
> in near future), so if somebody want to have this she needs to send a
> patch.
>
> > Your suggestion is fine for the defaults though.
> >
> > However, please, make this backward compatible. There are a number of
> > sites using Views and it is becoming really difficult to keep track.
> > Yes, I know it is in whiteboard, and that is the risk on takes, but
> > deprecating rather than removing would be more appropriate in this
> > stage
> > of the dispatchers development I would think.
>
> Like said this new locations will be added to the lm and they do not
> replace current ones. Sadly a @deprecate does only work on java files
> AFAIK, but we should update the docs that say to place it into the
> xdocs
> dir.
>
> Regarding backward compatible in general for views/dispatcher/... we
> said that we do not care about it.
Did we decide on a plan for removing those old
plugins and docs before releasing 0.8?
No, we have a couple of issues though:
http://issues.apache.org/jira/browse/FOR-798
http://issues.apache.org/jira/browse/FOR-797
It is nearly finished, but help is *very* welcome.
If you give me an example of what needs changing I will have a go over the
weekend.
At some stage soon we do need to worry about
backwards compatibility.
I would like us to get moving on solving the
general issues for the release, not just the
dispatcher ones. We are dragging on too long.
What are the general issues? Why do you think *we* are only focusing on
dispatcher ones?
Dispatcher is moving along quickly, and so I guess is receiving a lot of
focus
at the moment, which is good. I do think though that other issues are taking
a
back seat at the moment. I for one have been focusing my attentions on
getting
dispatcher working on my system, trying to find things I could contribute to
it,
this has the impact of me not looking at Jira for other issues that need
attention.
Anyway, this is an RT thread, so that is a topic
for another thread.
> More, I have reached the point in development (right now) where I see
> the dispatcher way too forrest specific and I want to remove all what
> is
> "forrest only". There should be no code in the dispatcher that forces
> the user to actually use forrest (forrest is one out of many excellent
> frameworks), the dispatcher is an independent component/framework (well
> heavily incooperating the lm) and should be seen as it.
I know that this is an RT, but would it be better
to get something that people can use and then we can
refactor later.
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).
Should the release of the Dispatcher from the Whiteboard come before, after
or at the same time as an official release of 0.8 ? Does releasing features
from
Whiteboard have an effect of a minor build release in its own right, whether
it be dispatcher, or a plugin or some other Whiteboard event ?
We have halted development on skins.
Now it looks like endless delays on the dispatcher.
It is not because of the dispatcher, the dispatcher is not delaying
anything! Forrest core is delaying the release not the dispatcher.
BTW we did not even start talking about releasing 0.8.
So lets talk about it, I guess we need to filter Jira for what IS holding up
a 0.8 release and go through them. Perhaps the next Forrest Friday should
focus on this. What are the improvements to Forrest other than dispatcher
that warrant there being a 0.8 release ? Are bug fixes and patches from 0.7
reason enough to release Forrest 0.8 without dispatcher being factored
into it -- or are most bug fixes and patches from 0.7 in the current 0.7
downloadable version ?
Should Dispatcher, although as you suggest, not part of the 0.8 release
program
and not holding up a 0.8 release, be moved from Whiteboard into core/plugin
at
the same time, now, or after ?
What are the incentives for users to upgrade to 0.8 from 0.7 ?
This is worrying.
Well, yes and there are more stuff that worries me.
> 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
> 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.
Is this a PMC decision, or should those now not currently active, mark
themselves as away for a while ? If it is a 'wish' then have a quick chat
about it
and do the neccessary, it might be an annoyance, but hardly a show-stopper,
so
get it sorted out of the way, or put it out of mind until more important
things are
out of the way.
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.
Being a subproject does not mean that people will not help out here on
forrest, but gives more freedom in releasing/refactoring and extending
the dispatcher.
What will this mean to the rest of Forrest, will those working on Dispatcher
then move away from Forrest to concentrate on it? This will impact I guess
on Forrests core development, but it might also mean those that are left can
concentrate on Forrest and just 'use' dispatcher in a fashion similar to
Forrest
devs just 'use' Cocoon. Not sure if this isn't such a bad idea after all.
> Further I am dreaming of a no-cocoon based
> implementation of the dispatcher, like as an extension for mozilla
> (written in POJ - I more and more understand Stefanos opinion "that
> cocoon has become obsolete").
Well that is Stefano's opinion. Also he hasn't
been involved in Cocoon development for a long time.
Being a researcher it is not surprising that he
keeps moving on to new things.
Forrest is still firmly based on Cocoon. We say so
in our project description. We need to be careful
not to destroy confidence by suggesting that it
is obsolete.
Well I did not suggest it but rather stated that I *understand* his
thoughts behind it. Let Forrest be firmly be based on cocoon but that
should not mean that *all* components (or subprojects) have to be based
on cocoon.
See e.g. the forrestbar, that has nothing to do with cocoon at all. Even
the dispatcher can be refactored relative quickly to be used in any
application that can connect to java classes (like firefox 1.5.x).
> That has as well the big advantage that forrest user do not have to use
> the dispatcher but can rather keep on using skins, which will stay the
> default rendering mechanism for forrest.
Huh? I thought that we were deprecating skins.
Lots of talk about it, but the reality seems different.
Perhaps we need to revisit that. Maybe we really
should provide two mechanims: skins and dispatcher.
If so, who will do this? Like you stated yourself:
"The number of truly active developers is very small."
The dispatcher originally started to overcome the downsides of skins and
actually it is (even in current development state) already better then
skins. Skins are *only* working in forrest, the dispatcher is a
standalone component.
Further if somebody has the itch to extract all skin related code [which
is deeply connected to the core, I tell from experience] into a skin
plugin, I am all for having the two mechanism (factor me out for doing
the skin plugins but I will help to remove all reference in the core to
skins). http://issues.apache.org/jira/browse/FOR-808
Having said this many times, I think we should let the dispatcher now
grow independent from forrest.
http://issues.apache.org/jira/browse/FOR-799
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.
Dispatcher to many is not complete, is still new and still in Whiteboard,
and I
guess the fact that more are currently still skins biased is because of
this.
The question is why would we want to keep skins as default and still not
allow the dispatcher to become a subproject for a bigger audience then
the forrest community?
Even if the dispatcher becomes a sub-project of forrest (like shale in
struts) we still can switch to the dispatcher as default any time.
You have a vision of Dispatcher that is bigger than most people here, the
fact
is that Dispatcher was born out of Forrest, from an idea based on skins and
all
its restrictions. Sure, move towards eventually making Dispatcher
standalone,
but I would not move it away from Forrest, although independent, Forrest I
would say relys on it in as much it relys on Cocoon. Without it, skins can
not
be deprecated.
I don't agree that skins should stay, that users have the choice of skins vs
dispatcher,
too messy, too confusing. Give them the choice, stay as they are with skins
and 0.7
and be supported with bug fixes for the time being - or upgrade to 0.8 and
later and
move onto the much nicer dispatcher., with I guess 0.9 removing skins
altogether.
Just my 2 cents :)
Gav...
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.3.0/290 - Release Date: 23/03/2006
