Paul Russell wrote:
Sure, there is certainly a need to tidy up things. But IMO the main need for that is in the field of webapps. The basic mechanisms for web publishing (which seemed to be your focus) works quite well, they can be improved in various way, but going for a revolution instead of an evolution requires more benefits than elegance.Hi Stefano,
On Wed, 23 Feb 2005 17:01:41 +0100, Stefano Mazzocchi
<[EMAIL PROTECTED]> wrote:
Paul Russell wrote:Thanks for the positives :) Fair enough - had a feeling that might be
So, let me know what you think! Am I mad? Is this a bad/good idea?
What have I missed? Is this something we should take further, or just
a distraction?
Paul,
first of all, I thank you deeply for having taken the time to write
this, there is a lot of thinking and you can tell, there is a lot of
good thinking and elegant design.. there is only one problem:
YAGNI
how you'd feel! There were some reasons for the ideas, related to some
of the feelings I've had for a long time about Cocoon, but you're
right in a way -- a lot of them are about tidying up compromises we've
made en route. Sometimes I think that's a necessary step though, if a
product is going to survive.
<snip/>
Whithout migration part and/or extremely convincing usecases you will find it rather hard to have any impact at Cocoon. Most of us have invested so much effort in, and based on, the current architecture so we need good reasons for introducing incompabillity.We some problems on the table, real, painful... and you propose
solutions to things that nobody really think they are a problem. Not me
at least. I think you will add a huge burden of abstraction for very
little functional benefit. I might entirely wrong, but it feels like a
2.0 syndrome: there is no incrementality and no plan to get there, no
requirements, just a whiteboard cleanup of all the little compromises
that have been made over time... and the goal is elegance, not simplicity.
You're right. The goal is elegance. Are you saying that you think doing a 'fresh job' of Cocoon 2 was a mistake? I'm surprised to hear that -- I still believe it was the only way to do it at the time.
You're absolutely right about the lack of migration path. What I'm
spelling out here is a vision -- after all, it is a random thought.
There are some things we could do to make a migration path, but most
of these are for us (e.g. providing Adaptors to wrap up existing
transformers etc.), not the users. The reason for this is simple: What
I'm discussing here is a fundamentally different way of doing things
-- the sitemap tooling approach for a start is 'just different'. It's
difficult to see how to make that kind of change incrementally.
I think you exagerate the problems to intoduce your ideas incrementally. Of course it means that you have to spend more time learning about the current state of Cocoon and our current ideas about its future, but that is necessary if you want to influence anyway.
Also, monolithic thinking is rather often a receipt for disaster, even if you work at your own. Everything gets so much easier if you start to deliver things that gives "customer value" early on, in that way you get relevant feedback early on as well. People get more and more reluctant in spending theire money and effort in thing that will be fantastic in the future but not will be of any interest at all until then. OTH your choice of project name seem to imply that you will deliver customer value (silk) early on ;)
Now if you want to join the party instead of doing everything your own way, I would suggest that you present one idea at the time. Your mail seemed to include some quite interesting ideas, start with the one that you find most important, write an RT about it, describe use cases and benefits for it and relate it to current mechanisms in Cocoon. By doing that it will be much easier for us to give you meaningsfull feadback and together with improve the ideas and maybe include them in Cocoon.
/Daniel
