RE: LongRunning tasks

Hi Christian,

See comments below...

At 10:49 AM 1/5/2004 -0500, you wrote:
>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.

Well, in name it was.  Our HttpServletRequestWrapper implemented 
HttpServletRequest with extra methods to account for those in servlet 2.3, 
but I don't believe we were married to the 2.3 api there.  We also use some 
2.3 features in various places in Barracuda, but only if servlet 2.3 is 
actually available.  Otherwise, we fall back to 2.2.  There are some 
servlet 2.3 specific features used in web.xml, but they aren't necessary to 
a working Barracuda and may simply be commented out for 2.2 
compatibility.  So, not until this move to using the 
javax.servlet.http.HttpServletRequestWrapper have we truly depended on 
servlet 2.3.  Again, I don't think this is bad, but I believe you have been 
one of the proponents of keeping 2.2 compatibility as long as we could get 
by with it.  That's why I was surprised by the change.

At this point, most any app server worth its salt supports servlet 
2.3.  Heck, Tomcat5 supports servlet 2.4.  I think we're safe.  Anyone 
still running Barracuda on Tomcat 3.x.xx?  I forget what Enhydra5.x.x uses 
as its Tomcat version internally?  Anyone know?  I know the goal was to 
move to a more recent version, but I'm not sure when the ETA for that was/is?

> > 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.

Ok, but that still doesn't address alternate client-types, since the code 
in Application Gateway is hardcoded to deal with only basic desktop HTML 
browsers only.

> > 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.

I should have mentioned something about the overhead of added features that 
some people might not care to use.  The extra code is bound to slow 
Barracuda down, even if it is hardly noticeable.  Being able to plug 
something in allows one to decide whether to take the extra hit or 
not.  BTW, it seems to me that this functionality might be added using a 
servlet filter.  Well, not sure on that one since I haven't thought about 
it much, but servlet filters truly fit this pluggability issue.  They are 
there only if you configure it in web.xml and are completely absent from 
the runtime when not provided meaning you don't take any hit when you don't 
want to and there is no extra logic in the core code.  Seems like the 
perfect fit!

>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.

Hmm...  I'm not sure that is the source of the steep learning curve.  I 
think it has more to do with lack of documentation on some of the core 
features.  Even I have to remind myself how things work sometimes.  I also 
think that a consistent centralized configuration scheme would help things 
here.  The use of Static variables can make things easy to configure for 
those who know all the different static variables to configure (with more 
being created all the time), but having something akin to XMLC's 
OutputOptions object or the like.  Something to wrap up all the 
configuration for the system.  A one stop shop for Barracuda 
configuration.  I haven't thought this through much, so take these ideas 
with a grain of salt, but I think the general idea makes sense.

>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.

If you are talking about Struts-like configuration, I totally agree.  What 
a nightmare that can be.  However, as I've stated above, making things 
configurable doesn't mean things are necessarily made harder.  It just has 
to be done thoughtfully.  Somehow Picocontainer ( 
http://www.picocontainer.org/ ) comes to mind as an interesting paradigm 
for this and other parts of Barracuda, but that's another topic for another 
day.

>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.

Yes, but to continue to add more and more stuff like this on top of 
Barracuda's core infrastructure in the same way that the long running stuff 
was added would sooner than later bog down Barracuda and make the code 
rather coupled and unintelligible, not to mention forcing features that 
some might not care to use.  Don't get me wrong, I totally agree that we 
need these more high level components.  But just like taglibs, they should 
be features that users explicitly declare that they want to use.  This 
doesn't have to be done though excessive configuration.  It should be as 
simple as adding a JSP taglib to web.xml.  Let's not overstate the 
difficulty or learning curve of this task.  It shouldn't be that 
hard.  Keeping the core clean should be a high priority (one of the 
highest, IMO).

>We also need a good
>sample app that shows how to use all these things and get people started
>quickly.

This is probably the highest priority.  I hope this can get done soon.  Any 
volunteers?

>  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.

Eclipse's pluggability is one of the biggest reasons for its 
popularity.  Ease of plugging new aha features in as if they were core 
services is pretty darn cool, if you ask me.  I think we could have the 
best of all worlds here:  a clean and blazing core with infinite 
pluggability of aha features.

>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...

Agreed.   The feature is definitely cool and useful in the real world and 
it does give us a kick start at thinking about the possibilities for 
building other useful high level components.

Jake

>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
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda