You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Johan Compagner <jc...@j-com.nl> on 2001/02/20 13:28:22 UTC
How does Struts compare to Barracuda?
Here is the link:
http://barracuda.enhydra.org/Barracuda/
Can we learn something from it?
Is it better or worse?
Johan
Re: How does Struts compare to Barracuda?
Posted by "Steven D. Wilkinson" <st...@acm.org>.
Dan,
Thank you for your 'instant analysis'. It sounds backed by a painful history of do-it-yourself. I would love to see
this thread continue.
You make some very good points about the Event/Listener model implemented over HTTP.
I have some questions...
I don't understand why the need to do an Event/Listener over HTTP?
Is it the firewall issue?
Isn't the browser also a problem?
Would the UI implemented in JSP or Applet/Swing?
Steve
> Dan Connelly wrote:
>
>
> Okay, that's a good question.
>
> Here is my instant analysis of Barracuda v. Struts. ("Instant" and therefore probably worthless. BTW, I haven't used
> Barracuda. And my experience with Struts is confined to toy applications.)
>
> Barracuda has apparently bitten of the Event/Listener model as its top-priority task. Struts has deferred this design
> decision until a later release. And there certainly are a ton of more mundane concepts to work through.
>
> The Event/Listener Model appears on the Struts 1.1 to-do list. My guess is that it will actually not make 1.1, that
> it will be delayed until 2.0 because of the massive refactoring required. Just guessing.
>
> The Barracuda docs say that the Event/Listener Model is the crux of the matter for leveraging MVC on the Web. Yes.
> Yes. Yes. Very True, IMHO. You screw it up, you lose.
>
> But also Very Difficult given the client-server division of labor in HTTP and the on-going Browser War. (Just one
> war, obviously.)
>
> It does seem wise to me that Struts should not make a hasty decision on its Event/Listener Model, but not past the
> point where it would break everything to put it in.
>
> When I worked on MVC apps in C++/Motif, we addressed this issue less generally, as Update Dependencies. We
> compiled the UD declarations into Mapping objects using a preprocessor. This seemed adequate for building lively
> apps and gave quite good performance, but Motif widgets had a much finer granularity of interaction in the application
> logic than do FormBeans.
>
> Of course, the Swing-style Event/Listener Model is much more run-time oriented in its approach than is a UD
> preprocessor. Java favors late binding. C++ favors early binding. It is a continuum. Each Framework needs to pick
> its spot on this continuum regardless of its implementation language.
>
> My guess, and it is just a guess, is that Struts will end up with some flavor of static UDs in the struts-config.xml,
> and that will be about the best you can do for HTTP Web apps.
>
> Barracuda will have to stick its hands very deeply into the DHTML mud to map the client-side events out to server-side
> objects. This is a mess. Once Barracuda is stuck there, then it falls victim to the "real" barracudas (the
> proprietary vendor interests) .
>
> If you need something very dynamic, very programmatic in your application's Event/Listener Model, then you need a
> different protocol than HTTP over the wire. Period. IMHO. Surely X-style "GUI Servers" will become part of the Web
> in due time. Same goes for Critrix-style "Terminal Servers". (Were it not for firewalls, this would already be
> true.) And if that doesn't happen, then look who's betting on SOAP (nee XML-RPC) to put events (as RPCs) on the
> wire. Clever marketing can easily morph SOAP into an Event/Listener Model on its own, eventually escaping HTTP
> altogether.
>
> Struts is wise to avoid this fray, for now. But, I'll bet that others in the Struts community feel strongly just
> the other way, that early engagement would be best. Maybe Barracuda has already done succeeded in mapping
> client-side events. ??
>
>
> Dan Connelly
>
>
>
>
>
>
> ----- Original Message -----
> From: "Johan Compagner" <jc...@j-com.nl>
> To: "Struts" <st...@jakarta.apache.org>
> Sent: Tuesday, February 20, 2001 7:28 AM
> Subject: How does Struts compare to Barracuda?
>
> > Here is the link:
> > http://barracuda.enhydra.org/Barracuda/
> >
> > Can we learn something from it?
> > Is it better or worse?
> >
> > Johan
> >
> >
--
-----------------------------------------------------------------
Steven D. Wilkinson, stevendwilkinson@acm.org
Re: How does Struts compare to Barracuda?
Posted by Craig Tataryn <Cr...@msdw.com>.
I aggree, mapping DHTML events to server side handlers would be icky,
and tough to support accross browsers. Using a more cleaner UI def like
XUL (http://www.xulplanet.com/) is probably a better idea (although
there is only one browser supporting it thus far, although I'm sure
someone could write a plugin to support it in IE).
I like your comment on the firewall preventing more of the dynamic type
webapps (see my article on XSpot
http://www.us-eh.com/craiger/articles/xspot/), it's so true.
<tataryn:craig/>
Dan Connelly wrote:
> Okay, that's a good question. Here is my instant analysis of
> Barracuda v. Struts. ("Instant" and therefore probably worthless.
> BTW, I haven't used Barracuda. And my experience with Struts is
> confined to toy applications.) Barracuda has apparently bitten of the
> Event/Listener model as its top-priority task. Struts has deferred
> this design decision until a later release. And there certainly are
> a ton of more mundane concepts to work through. The Event/Listener
> Model appears on the Struts 1.1 to-do list. My guess is that it will
> actually not make 1.1, that it will be delayed until 2.0 because of
> the massive refactoring required. Just guessing. The Barracuda docs
> say that the Event/Listener Model is the crux of the matter for
> leveraging MVC on the Web. Yes. Yes. Yes. Very True, IMHO. You
> screw it up, you lose. But also Very Difficult given the client-server
> division of labor in HTTP and the on-going Browser War. (Just one
> war, obviously.) It does seem wise to me that Struts should not make a
> hasty decision on its Event/Listener Model, but not past the point
> where it would break everything to put it in. When I worked on MVC
> apps in C++/Motif, we addressed this issue less generally, as Update
> Dependencies. We compiled the UD declarations into Mapping objects
> using a preprocessor. This seemed adequate for building lively apps
> and gave quite good performance, but Motif widgets had a much finer
> granularity of interaction in the application logic than do
> FormBeans. Of course, the Swing-style Event/Listener Model is much
> more run-time oriented in its approach than is a UD preprocessor.
> Java favors late binding. C++ favors early binding. It is a
> continuum. Each Framework needs to pick its spot on this continuum
> regardless of its implementation language. My guess, and it is just a
> guess, is that Struts will end up with some flavor of static UDs in
> the struts-config.xml, and that will be about the best you can do for
> HTTP Web apps. Barracuda will have to stick its hands very deeply into
> the DHTML mud to map the client-side events out to server-side
> objects. This is a mess. Once Barracuda is stuck there, then it
> falls victim to the "real" barracudas (the proprietary vendor
> interests) . If you need something very dynamic, very programmatic in
> your application's Event/Listener Model, then you need a different
> protocol than HTTP over the wire. Period. IMHO. Surely X-style
> "GUI Servers" will become part of the Web in due time. Same goes for
> Critrix-style "Terminal Servers". (Were it not for firewalls, this
> would already be true.) And if that doesn't happen, then look who's
> betting on SOAP (nee XML-RPC) to put events (as RPCs) on the wire.
> Clever marketing can easily morph SOAP into an Event/Listener Model on
> its own, eventually escaping HTTP altogether. Struts is wise to avoid
> this fray, for now. But, I'll bet that others in the Struts
> community feel strongly just the other way, that early engagement
> would be best. Maybe Barracuda has already done succeeded in mapping
> client-side events. ?? Dan Connelly ----- Original Message
> -----From: "Johan Compagner" <jc...@j-com.nl>To: "Struts"
> <st...@jakarta.apache.org>Sent: Tuesday, February 20, 2001 7:28
> AMSubject: How does Struts compare to Barracuda? > Here is the link:
> > http://barracuda.enhydra.org/Barracuda/
> >
> > Can we learn something from it?
> > Is it better or worse?
> >
> > Johan
> >
> >
--
I've been trying to change the world for years, but they just won't give
me the source code....
Re: How does Struts compare to Barracuda?
Posted by Dan Connelly <ds...@adelphia.net>.
Okay, that's a good question.
Here is my instant analysis of Barracuda v. Struts. ("Instant" and therefore probably worthless. BTW, I haven't used Barracuda. And my experience with Struts is confined to toy applications.)
Barracuda has apparently bitten of the Event/Listener model as its top-priority task. Struts has deferred this design decision until a later release. And there certainly are a ton of more mundane concepts to work through.
The Event/Listener Model appears on the Struts 1.1 to-do list. My guess is that it will actually not make 1.1, that it will be delayed until 2.0 because of the massive refactoring required. Just guessing.
The Barracuda docs say that the Event/Listener Model is the crux of the matter for leveraging MVC on the Web. Yes. Yes. Yes. Very True, IMHO. You screw it up, you lose.
But also Very Difficult given the client-server division of labor in HTTP and the on-going Browser War. (Just one war, obviously.)
It does seem wise to me that Struts should not make a hasty decision on its Event/Listener Model, but not past the point where it would break everything to put it in.
When I worked on MVC apps in C++/Motif, we addressed this issue less generally, as Update Dependencies. We compiled the UD declarations into Mapping objects using a preprocessor. This seemed adequate for building lively apps and gave quite good performance, but Motif widgets had a much finer granularity of interaction in the application logic than do FormBeans.
Of course, the Swing-style Event/Listener Model is much more run-time oriented in its approach than is a UD preprocessor. Java favors late binding. C++ favors early binding. It is a continuum. Each Framework needs to pick its spot on this continuum regardless of its implementation language.
My guess, and it is just a guess, is that Struts will end up with some flavor of static UDs in the struts-config.xml, and that will be about the best you can do for HTTP Web apps.
Barracuda will have to stick its hands very deeply into the DHTML mud to map the client-side events out to server-side objects. This is a mess. Once Barracuda is stuck there, then it falls victim to the "real" barracudas (the proprietary vendor interests) .
If you need something very dynamic, very programmatic in your application's Event/Listener Model, then you need a different protocol than HTTP over the wire. Period. IMHO. Surely X-style "GUI Servers" will become part of the Web in due time. Same goes for Critrix-style "Terminal Servers". (Were it not for firewalls, this would already be true.) And if that doesn't happen, then look who's betting on SOAP (nee XML-RPC) to put events (as RPCs) on the wire. Clever marketing can easily morph SOAP into an Event/Listener Model on its own, eventually escaping HTTP altogether.
Struts is wise to avoid this fray, for now. But, I'll bet that others in the Struts community feel strongly just the other way, that early engagement would be best. Maybe Barracuda has already done succeeded in mapping client-side events. ??
Dan Connelly
----- Original Message -----
From: "Johan Compagner" <jc...@j-com.nl>
To: "Struts" <st...@jakarta.apache.org>
Sent: Tuesday, February 20, 2001 7:28 AM
Subject: How does Struts compare to Barracuda?
> Here is the link:
> http://barracuda.enhydra.org/Barracuda/
>
> Can we learn something from it?
> Is it better or worse?
>
> Johan
>
>