Stefano Mazzocchi wrote: > > These RT propose two things: > > 1) move out flow as a block > 2) make the sitemap syntax pluggable > Yes, but I see 1) as a need and would be happy about 2).
> - people use cocoon in a non-servlet environment and would like to see > all servlet hooks removed Yes. > > - people don't like/use XSP and would like to see dependencies on java > compilers removed Big Yes :) > > - people don't like/use the flow and would like to see support for it > removed Yupp. > > - people don't like/use actions and would like to see support for it > removed No, like Nicola said, these are usual sitemap components. Ok, I see your point here, but I think simple actions are used very commonly. > > - people dont' like/use the avalon instrumentation and would like to > see support for it removed Yes. > <snip/> > it would turn the sitemap into Jelly: people will define ask us to > include a feature in the sitemap, we'll reject it, he'll host in on > sourceforge and since it's a clever hack with tons of problems down the > road but very appealing at first everybody starts using it. Yes, I'm fully aware of these dangers - and that's why I'm more interested in moving flow into a block (or module or whatever) than in making the sitemap pluggable. But: during the last two years, from time to time I had the need to extend the sitemap syntax, because that would have made some things much more easier. As it was not possible, we used some other methods like actions etc. > > We should start thinking about modules and how to factor out things, but > the sitemap should *NOT* be modifiable by those modules. The sitemap > must remain carved in stone and only *US* cocoon development community > (as a whole, not me, not you) should define it and keep control of it. Agreed. > > If you want to experiment, we give you scratchpad to incubate your > ideas, but I don't want to make it easy for people to add contracts > inside cocoon. > > At the end, my thoughts are: > > 1) I won't be against having a way to remove dependencies on internal > 'modules' that are not used (I listed some of them above) > > 2) I will be against making it any easier to modify/extend the sitemap > semantics. > Ok. How can we then make flow a block (or a module)? Carsten
