cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Recent Short Story Why We Need Something New
Date Mon, 05 Dec 2005 14:33:35 GMT
I'm not going to take too long, but this is just anecdotal evidence of 
why I think Cocoon 2 is stagnating and we really need a Cocoon 3.  Let's 
roll back the calendar just a couple short months ago just before the 
Cocoon Get Together.

I proposed a change to the way Cocoon would process a request.  Now, in 
the original 2.0 code it would have been fairly easy as we had a pretty 
simple Processor interface.  I received lot's of "why write Java code 
when you can use JavaScript" comments.  The "you can do that already, 
just set your Sitemap like this, and set up a flowscript like that, and 
viola" approach was really more complex than I wanted.  I dared to ask 
the question, "why?"  It would become just meaningless cruft to do 
that.  So I made the statement "let me show you what I mean" and I 
started something in the whiteboard called "crails".

It became immediately apparent that I could not possibly do what I 
wanted with the current architecture.  Too many concerns made their way 
into the Processor interface, and I would _need_ to rewrite _major_ 
portions of Cocoon code just to provide an alternate processor to the 
Sitemap.  Honestly, at this point, it would be easier to just start 
Cocoon over from scratch trying to fit in as much as I could from the 
existing codebase.  But it was ugly and I really wasn't comfortable 
doing that without more than _just_me_ doing the work.

I'm a busy guy, and I can contribute here and there.  I can whip up a 
few simple solutions but I can't rewrite Cocoon on my own.  I'm reading 
two books, writing one, doing OSS, and that's all in addition to my day 
job and family.  To be honest, we need to cater to people just like me.  
It shouldn't take a long time to get into the internals of Cocoon.  Even 
if I never do get into the internals, I should be able to do some value 
add.  I shouldn't need to learn seven different tools and languages just 
to do something simple.

There should also be the principle of ever deepening knowlege.  Looking 
at things from the electronics perspective, building a solid state 
electronics based mic amplifier is very simple because op-amps are built 
to tolerance, and they don't require alot of finessing.  As a result you 
can build much more into the amplifier, such as filters attenuators, 
etc.  Contrast that with tube electronics, and its a different story.  
Yes, the final circuit board for a tube system is simpler, but there is 
so much math and fine tuning just to get the thing to work you are just 
happy you've got something that amplifies your microphone.  You don't 
care about attenuators and filters, because they would be too much 
effort.  The tolerance on tubes are not nearly as strict, so your 
circuit may work with the next tube or it may not.  It depends on a few 
factors.

Cocoon 2 is like working with tubes.  There is so much up front work 
that as a user I am just happy I have something that works.  Adding all 
the fun stuff for my users tends to go on the back burner because I 
wrestle with the framework.  The solution?  Well either change Cocoon, 
or change frameworks.  For me, I decided to change frameworks for my 
personal projects.  My needs don't require all the power of Cocoon, but 
it would be nice to provide some options.


Mime
View raw message