Hi guys,

Normally I just lurk here, but I did want to comment on a stmt pertaining to
Barraucda.

> >Barracuda is an impressive framework. It also has quite a
> >powerful event model which struts lacks. The rendering seems
> >tied to XMLC however.

Barracuda, as its currently implemented _is_ tied to XMLC in two specific
places: it uses XMLC to load the DOMs, and it uses XMLC to actually render
the processed DOMs. But that's it - everything else is specific to the DOM
api; we designed it that way intentionally. So decoupling from XMLC is
fairly straightforward - you provide something to load the DOM, and you
provide a renderer to actually stream the processed DOM back to the client.
That's it. Now, we don't have another loader/renderer currently in the
project, but that is on the todo list (Q1 2003 hopefully).

> >it must be said from this experience that struts certainly
> >doesnt tie you down to a particular view technology. :-)

Just to be clear, Barracuda doesn't tie you to a particular rendering
technology either; it is possible to use just the event model and to skip
the component stuff altogether. Heck, you could actually probably use
Barracuda as your controller and JSPs to render if you really wanted to.
What Barracuda _doesn't_ try to do is make it any easier to JSP related
stuff...if you need to use JSPs, then there are plenty of frameworks out
there to consider (and Struts is certainly among the best I've seen).

> Struts is exciting because it has such momentum.  Barracuda is
> exciting because it is the most complete MVC framework I've seen.

I think this is a fair assessment (of course I'm biased ;-) Struts does have
momentum, but the question is "why"? After all, MS's .NET stuff has momentum
too...

My point here is simply that momentum does not _necessarily/automatically_
mean something is good; coporate interests on both sides of the isle
regularly try their hardest to generate momentum as a means to achieving
developer adoption. This is particularly true of MS, but Sun does it
too...there are many reasons that they have hitched their horses to the JSP
wagon, but one of the major ones has to do with positioning against MS's ASP
(not the architectural pro's/con's of JSP over and against other
alternatives).

Now, please note that I'm _not_ suggesting that all of Struts momentum has
been manufactured; if you're stuck with JSP, then Struts is a lifesaver. The
great thing about a project like Struts (and other open-source efforts) is
that most of the growth comes from the community, rather than the industry;
its driven from the grassroots.

What I _am_ saying however, is that Barracuda was not created for the
purpose of generating momentum (well, maybe that's what Lutris wanted). The
primary focus of the developers involved, however, was to step back and say
"let's try really rethinking this whole problem space and see if we can come
up with a way to really do it right". And so we evaluated all the other
approaches we could find, and tried to learn from them, and tried to apply
lessons learned from client-server development in a stated environment. But
the emphasis was on architecture, not momentum.

I've always felt that if Barracuda could get the architecture right, then it
would make it much easier to build the type of RAD tool integration that
made client server development so much easier, and that in turn would take
care of any momentum issues. What actually amazes me is the measure of
adoption Barracuda has already achieved, given the fact that we've still
been focusing on architecture rather than ease of use.

At any rate, I've digressed. Sorry to take up Struts bandwidth talking about
Barracuda, but I think that both projects have good ideas and figure a
little intellectual cross-pollination never hurt anyone.

Cheers!
Christian
----------------------------------------------
Christian Cryder [[EMAIL PROTECTED]]
Internet Architect, ATMReports.com
Barracuda - http://barracuda.enhydra.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to