RE: LongRunning tasks

Hey Jake,

Good comments as usual.

> So, we are officially not servlet 2.2 compatible anymore, eh (because of
> the new use of the servlet 2.3+ HttpServletRequestWrapper)?

I _think_ we've actually been tied to 2.3+ for a bit now...the
HttpServletRequestWrapper stuff was already in there (with methods for 2.3
compliance), although I renamed the class.

> Not sure I agree with the change in ApplicationGatway where HTML code is
> written out for the long running stuff.  First, that means that long
> running events are only supported for HTML clients such as web browsers
> and not other clients such as WAP phones and such.  Plus it doesn't
> seem right for the front controller to be writing markup to the client
> anyway.  That should be done in another layer, IMO.
>
> Also the fact that XMLC is being used by the core of Barracuda when
> Barracuda is supposed to be (relatively) agnostic on DOM
> implementations.  This means that if one wants to use, for
> instance, Jivan instead of XMLC, XMLC will still have to be available to
> account for Barracuda's internal use of XMLC.  Seems like this forces
library
> bloat on users.

I agree with most of this in principle - it could certainly be better, more
pluggable, etc. But at this point, I simply don't have the time to go make
it do those things, so it will have to wait until someone wants to improve
it (patches welcome! ;-) The good thing is, the general logic should remain
pretty much the same regardless of where we are getting our DOM source.

> Features like this ought to be able to be plugged in...Additions like
this,
> be they cool or not, make Barracuda inevitably more complex.  Users should
be
> able to add features like this in if they want them and leave them out if
> they don't.

Just to clarify - additions like this make the _Barracuda code_ more
complex; but they make _Barracuda as a framework_ much more powerful and
easy to use. And that's a big difference. Per your email the other day about
"ease of use" (which I still mean to respond to) - one of the things we are
going to have to deal with is how to make Barracuda easier to use, and in
general, making the framework so users have to decide what to add in and
what to leave out is actually something that makes it harder to use, because
they have to understand how it works in order to understand how to configure
it. Indeed, I think part of Barracuda's steep learning curve comes from the
fact that we made it so configurable in the first place, even though the
majority of people aren't ever configurring it. This is part of the reason
why I implemented it the way I did - to make it as simple as possible for
people to use; they don't have to do any configuration of Barracuda -
everything's already there by default.

Now, none of this is meant to negate your point: a) the code could certainly
be cleaner, b) it would probably be nice for it to be more pluggable, and c)
we really do need to think about these things for Barracuda 2.0. All I'm
trying to say is that we need to realize that configurability actually
_increases_ complexity. And so we want to make it possible to configure
stuff, but we also want to do more in the way of default implementation that
makes all the decisions for the user. That's the type of thing that will
make the framework easier to use.

One final comment about Barracuda's "value proposition". I think the
perceived value of the framework, will not be so much in terms of the
component or event models, but rather the higher level "components" that we
build with it. For instance, what we've really done here is create a "Long
Running Component" (in a meta sense) - you can configure it, supply your own
template, etc. That's something that developers will go "wow...this saves me
_tons_ of time...I've _got_ to use this framework". In my opinion, that's
the type of reaction we need to be seeing in order to see Barracuda continue
to grow and prosper.

Along these lines, I think we need to consider creating components for like
Reports, Maint screens, dialogs, calendars, etc. All of these are components
in the high level, "meta" sense - they consist of templates, models for
populating those templates, some business logic, etc. We also need a good
sample app that shows how to use all these things and get people started
quickly. At any rate, all I'm saying here is that I think this is the type
of thing that is going to elicit "ah-ha" moments more than how pluggable we
make the internal implementation.

Of course, how best to implement it all remains to be seen, but stuff like
this LongRunning stuff at least gives us a tangible example to start
thinking about...

Christian
----------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jacob Kjome
> Sent: Monday, January 05, 2004 1:35 AM
> To: [email protected]
> Subject: Re: [Barracuda] LongRunning tasks
>
>
> Hi Christian,
>
> So, we are officially not servlet 2.2 compatible anymore, eh (because of
> the new use of the servlet 2.3+ HttpServletRequestWrapper)?  Fine
> by me as
> long as everyone else is ok with it.
>
> Not sure I agree with the change in ApplicationGatway where HTML code is
> written out for the long running stuff.  First, that means that long
> running events are only supported for HTML clients such as web
> browsers and
> not other clients such as WAP phones and such.  Plus it doesn't
> seem right
> for the front controller to be writing markup to the client anyway.  That
> should be done in another layer, IMO.
>
> Also the fact that XMLC is being used by the core of Barracuda when
> Barracuda is supposed to be (relatively) agnostic on DOM
> implementations.  This means that if one wants to use, for
> instance, Jivan
> instead of XMLC, XMLC will still have to be available to account for
> Barracuda's internal use of XMLC.  Seems like this forces library
> bloat on
> users.
>
> Anyway, the functionality seems pretty cool.  Seems like it could
> have been
> implemented slightly cleaner, though.  Features like this ought
> to be able
> to be plugged in.  I'm not saying I have the answer for how to do
> that, but
> I think we need to sit down and think about how to simplify the core of
> Barracuda.  Additions like this, be they cool or not, make Barracuda
> inevitably more complex.  Users should be able to add features
> like this in
> if they want them and leave them out if they don't.  Maybe a
> discussion for
> Barracuda 2.0?
>
> Jake
>
> At 06:20 PM 1/4/2004 -0500, you wrote:
> >I just checked a pretty massive change into cvs - this to add built in
> >support for Long Running tasks from with Barracuda. Check here for more
> >details: http://barracudamvc.org/Barracuda/docs/events/long_running.html
> >
> >Comments and feedback welcome...
> >
> >Christian
> >----------------------------------------------
> >Christian Cryder
> >Internet Architect, ATMReports.com
> >Project Chair, BarracudaMVC - http://barracudamvc.org
> >----------------------------------------------
> >"Coffee? I could quit anytime, just not today"
> >
> >_______________________________________________
> >Barracuda mailing list
> >[email protected]
> >http://barracudamvc.org/lists/listinfo/barracuda
>
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda