Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v734)
In-Reply-To: <433DCEBA.2030403@umn.edu>
References: <433DB4B5.8070703@apache.org> <433DCEBA.2030403@umn.edu>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <101F63C8-9577-49A3-BA8B-6C21F3A3B3F3@luminas.co.uk>
Content-Transfer-Encoding: 7bit
From: Andrew Savory <andrew@luminas.co.uk>
Subject: Re: [RT] Is Cocoon Obsolete?
Date: Sat, 1 Oct 2005 15:23:58 +0100
To: dev@cocoon.apache.org

Hi,

I think Stefano raises some interesting issues, but there's a flaw in  
the premise: is everything we do in Cocoon targeted at a browser- 
based client model? I don't think so. It discounts Cocoon as an  
integration framework, an XML-based service bus (urgh, buzzword bingo  
time), and Cocoon as a solution for client platform independence.

That said, I do think there'll be massive challenges in working with  
the rich client world, when the "transform it all on the server side"  
model becomes less relevant. Stefano's absolutely right about the  
challenges these rich clients bring to server-side frameworks. And I  
surely agree that Cocoon itself has complexity issues, which brings  
us to Tony's points...

On 1 Oct 2005, at 00:48, Tony Collen wrote:

> 1.  (Like Berin) I am admittedly infatuated with Rails.  This may  
> be the infatuation speaking, but the "Rails doesn't scale" smells  
> like FUD to me.

Not so much FUD as much as a practical statement - I'm sure it will  
scale, but as with every new framework, the Rails folk need to put  
some work in to make it handle the complex stuff just as well as it  
currently handles the simple stuff. The benefit of beginning from a  
simple premise ("write less code", "convention over configuration")  
is you get to start with no preconceptions on how to do things, and  
make life easier for the developer. The downside is you then need to  
meet developer expectations consistently - and keep things simple all  
the way up the stack. IMHO, Rails is not quite there yet.

> 3. More functionality is moving to the browser, but the apps will  
> still reside on servers. I can't see that moving away.  I always  
> knew server-side XSLT was sort of a stopgap until browsers could do  
> it reliably.

I think this may be true for display-based XSLT processing, but I  
think it misses out rather a lot of pre-display processing that goes  
on. I'm also not entirely convinced large companies will be happy  
about sending out their content and presentation as separate  
packages. My bet is server-side XSLT is here to stay, for quite some  
time.

> - Simplify Cocoon.

Heheh. Someone should do a talk about this at the GetTogether. Oh,  
wait .... ;-)

This is exactly the point I'm hoping to get across - helping our  
users with convention over configuration, less XML sit-ups, providing  
a clearer "best practice" and a way to hit the ground running right  
away.

> What's the bare minimum we can get away with?   Not only  
> functionality, but also actual amount of code?  Ugo's work with  
> Spring and Butterfly probably is a good starting point.

I can't help with the internals of Cocoon (it's way over my head),  
but I hope I can provide a starting point for lowering the learning  
curve of Cocoon beginners. If I manage to get the code working, I'll  
drop it into the whiteboard alongside Bertrand's.

> Tony, who feels like he dumped a lot of stuff from his brain  
> because of Stefano's RT.


Andrew, who feels like with every passing day more of the ideas of  
his presentation crop up on the mailing lists before he's had a  
chance to present them ;-)