- people don't like/use actions and would like to see support for it removed
No, like Nicola said, these are usual sitemap components.
I don't use actions nor like them so they are not 'usual' for me as much as flow is not 'usual' for you if you don't like nor use it.
Ok, I see your point here, but I think simple actions are used very commonly.
I could well say this is because there was no other way of solving issues, but now that there is, things might change a lot, we just don't have information on this (yet).
- 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.
Good.
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.
Having a solid contracts doesn't mean we can't extend it if a real need emerges.
I'll be happy to discuss any needs for changes that appeared in your needs.
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.
Good.
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)?
Create a way to have internal parts of cocoon to be removed at compile time.
The sitemap semantics remain the same: just like we don't remove map:act, we don't remove map:flow but cocoon will run even if there is no rhyno in the classpath and will give you an error message like
'flow is not supported in this build'
or something like that. The same can be done for actions.
so, if you want to ship your cocoon without stuff you do the equivalent of
./configure --disable-flow --disable-xsp
What do you think?
