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 ;-)
