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" <[EMAIL PROTECTED]>
> To: "Struts" <[EMAIL PROTECTED]>
> 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, [EMAIL PROTECTED]
