ApacheCon
Monday - Keynote
Delivering today's keynote is Will Wheaton, that guy from StarTrek who now has a weblog. His key point is that the web is reinfrancising the little people and allowing grassroots efforts in an important way. This is not the newest point I've ever heard raised, but he's using a few funny stories about penny-arcade.com and so forth, so it's not that bad a keynote speech.
Aaron fitzpatrick - thread safety talk
This talk is basaed araound APR - the core of which is the GLUE code - a layer that provides access to DB, socket, etc.
Interesting project, mostly geared towards incresing the flexibility of multithreading.
Several different mutex types re made vilble: thread, proc, and global level to customize resource protection.
The mutexes are nested, allowing code to lock resources within another lock, though this hs efficiency costs.
Also provides a rw sensitive locking API, which is awfully useful, and significantly faster than Mutex, especially for reads. The read-write locks that APR provides are very fast - better scalability.
Condition variables for thread communications, to notify about changed data, events, etc.
MPM is a way to customize the way server does threading, chosen at the top level, and supports some wild and crazy tradeoffs, like one thread per request, etc.
So, how does this integrate with Apaache 2.0: hmm - looks like this is apache_mod hook based - can we use any of this? Moly, there's C on the screen two seconds after I typed that. ;)
We're now doing an overview of various ways this can be used, shared memory, cond variables, Userdata hashes from above, etc...
Graphical proof that linux is wierd and solaris is very good with locking.
Major issue for Catalyst is tht this is enitrely oriented towards Apache module development - not something we're currently in the business of doing. Patrick suspects that the mod_perl developers will be using this technology to make our life easier, and he's right, it is their job, not ours.
Comparing Web Frameworks - Matt Raible
All of the frameworks being compared are Java, and the guy next to me called me a luddite for using VIM. So, now that you know the atmosphere.... All the code is being exhibited in a very complex OS X IDE, probably Eclipse.
The Lineup:Struts This is the standard professional framework at the moment, as evidenced by the huge number of job listings and sheer amount of community support. It has the best taglib as well (Taglibs are the HTML wrangling routines, used for formatting things, creating data tables with JS controls and associating inputs/controls with object attributes and so forth.)
On the negative side using an older, more cumbersome object model called ActionForms is still the best way to handle user forms. Also, doing isolated unit tests is difficult, though Struts does include a builting set of testing libraries. On the can't-believe-what-I-just-heard side, the speaker just listed the huge size of the Struts maililng list as a Con. He said he unsubscribed because he couldn't handle the traffic! Pine! Or anything with filters for crying out loud.
"Equinox" is a cute little example app on Java.net.
Spring MVC This is a versatile more backend/programming model oriented project that integrates well with different views. It adds an additional layer of abstraction between the displayed form view and the submitted form view which can be useful. This is an interesting concept from the user experience perspective as it would allow really adaptive behavior that could provide valuble and quick feedback to their actions.
On the downside the community around SpringMVC is still small. Also, lots of code ends up in the JSP (mingled with HTML) as SpringMVC wraps all its widgets in Java objects and deals with errorlabels alongside these widgets as well.
SpringMVC appears to contain a strong controller hierarchy similar to ours, and one of the most "revolutionary and interesting" features was a function life-cycle very similar to the Catalast controllers'.
WebWork Billed as very simple and easy to use and expand, WebWork seems to live up to this. It has a one-function controller model (think "run", Catalyst folk) but allows "interceptors" to be associated with controllers to affect the flow and behavior. Combined with a useful taglib this makes for an easy framework to learn.
Unfortunately the documentation is weak and scanty, and the client-side validation is poor. Notice this please, as at this point I noticed for the first time that client-side validation as a part of the framework was assumed for all these frameworks, and mentioned only when it was lacking or poor!
Tapestry Tapestry is apparently unique among these frameworks and does things in a fairly different way, though I didn't hear enough about that way to satisfy me. Some of the strengths were a pure HTML templating setup, keeping the JSPs very clean, and a complete mask of the servlet API ("The way it should be!" someone shouted), and a fanatical community.
The documentation available tends to be more conceptual than pragmatic, however, which is a mixed bag, according to the speaker, since you need some conceptual understanding to adjust to Tapestry's way of doing things. This factor contributes to the overall steep learning curve.
I observed in the code a "RequestCycle" object which I think was being used to control the lifecycle functions of controllers: Set a list of controllers into it and it steps them through the getView, update, validate, commit cycle. (note that this was absorbed from a quick look at code, might not be accurate, but it's at least an interesting idea...)
JSF: Java Server Faces This is a J2EE standard compliant framework, whatever that means, and it sports the best navigation framework among the frameworks covered. It keeps a state/transition table in XML, which was listed as a plus, and generally easy to work with.
The community is not as strong as some of the others. Additionally the taglibs are a problem as they generate tagsoup that gets injected into JSPs. Also, the code displayed was Java at its very worst, single lines wrapping two/three times on dotted method calls, but the speaker is pointing this out as a con as well.
Controllers and Views Webwork falls short as it just has an execute/run method, but remember the interceptors.
Taglibs Looks like there are a pretty significant body of taglibs available, we saw two frameworks render a sorting list/table nicely using different methods.
Bookmarking WebWork has app/page namespaces and URLs which makes it easy. Struts also allows full URL control, but programmtically. JSF uses all posts for clicks which was considered a problem. (We do this)
Validation Struts/Spring use something called the "Commons Validator" which is supposed to be good server and client side. Webwork makes successful use of OGNL, while Tapestry includes very robust validation as a builtin. JSF was dismissed as "nasty."
Testability: Struts builtin Mocks - various implementations for various frameworks Tapestry has something prop. builtin.
Success messages Mixed bag here - Struts looks best, Tapestry allows this via a hack, all the others require custom work. This might be a good idea - we already have MessaageService, and this kind of feedback could be very reassuring.
Spring Integration All the frameworks work with Spring.
Decoration Tiles, SiteMesh are both good, but SM is apparently recommended. Should we consider doing more proactive style/decoration handling in our framework?
IDEs Available Sweet in general except for JSF. Tapestry has the "Spindle" plugin for Eclipse, which is apparently quite useful.
Overall Thoughts All of these have extended tags in JSP that work with the framework. PerlInHTML might be our recourse here, if we wanted to do a little HTML work based on objects, but it would probably be a better idea to just write some taglibs that all these Java buffs are taking for granted and leave everything powered by HTML::Template.
There were lots of head nods to editors/designers making use of WYSIWYG tools - will this apply to us as PETT becomes integrated?
Cilent side validation was taken for granted as a part of the framework, and we already had a rant about how badly we need to wrap our form validator and a clientside validator up into Catalyst::Validate, so I'm gonna let this speak for itself.
In general, the expectations for the frameworks are signficantly higher than for our own, but mostly in terms of the views and client-side capabilities of the taglibs, widget/input/button wrappers, validation etc.
jscalendar.sourceforge.net was ubiquitous among these frameworks, is that what we use?
Wow, the live demonstration is spewing catalina errors and we had to wait a minute and a half waiting for Tomcat to start, which people are not batting an eyelash at.
What is a "command" object? He's getting the user from it just by a cast. Let's look this up.
Logging and Configuration - Henning Schmiedenhausen
Constants are the old way to configure things.
JDK has java.util.properties, which just loads key=value elements and sounds similar to Catalyst::Configure.
XML is in vogue (think Shib) but cripes it's complex (think Shib).
The Jakarta commons config is pretty good. It has a drop-in replacement for java.util.properties and is more flexible in terms of datatypes, defaults, arrays.
This is obviously pedantic and heavily java oriented - notetaking has ceased.
Building Webapps with Beehive - Rich Feit, Eddie O'Neil
Pageflow Beehive appears to be a framework that is defined by the addition of JSR metadata tags to the Java code.
These annotations control the way any given user request is handled by directing them through "page flows."
On the less technical side, this seems to introduce the nice concept of pageflows, which are entities within session, so that many can be used by one user concurrently or nested. This looks like it could provides a nice navigational and task-based workflow, both for the user and the programmer.
Also raised is the issue of shared flow - default behavior for things like logins - any time a page flow raises a notloggedin exception route them through the login flow. Sort of a superclass for transitions.
Views He's taking the association of inputs with data routes and model attributes for granted - we do not do this! It would be great if our models defined the widget used to set them, and associated that info with the widgets.
Questions
I don't know much about the metadata standards that he's dealing with, but is the use of metadata to shape execution flow an abuse? How is this different from what we do? And lord
is this code ugly - two totally different language standards smashed together, with some bleed into the JSP too, as seen below.
Apache 2.0 mod_ssl by Example - name deleted
Wow this is truly painful.
I cannot read anything on the screen, and the speaker is mumbling and grunting. Sorry, but this useless interlude is only being endured so we can get to the "revolutionizing webapp development" session in an hour. ;)
Continuations - Revolutionizing Webapp Development - Torsten Curdt
Better way of planning webapps is MVC, not screen flow.
But, asas we know, state diagramming can be difficult. He's outlining the trouble that the Beehive people addressed with the pageflow abstraction, and his solution is very close - the Cocoon software provides a similar flow abstraction, but encoded in the controller. As Patrick pointed out earlier while we chatted about Beehive, we have this level of abstraction at the "application" level, but we are not currently using it.
The controller he is envisioning is much higher-level, and has encoded a flow which can be started and stopped... it appears that session/state is more or less contained within the controller.
Apparrently, the state for each controller step keeps context, so that backing up starts a new "continuation" with a full cloned session context.
Questionss:
When is cleanup going to be done, and how big is this gonna get with all these session contexts hanging around?
He replied that there is a garbage collector, but that it is not much of an issue, because continuations are not big objects.
how is this possible? Can they be smaller than session? Yes, but there is a session per continuation...
Also - how does one return to an abandoned continuation? This hearkens back to my idea of keeping all the button id's in a table so we could recognize which state generated them and at least catch back-button use. Can this method (which we already implement) be used to make intellegent choices about when to allow a possible continuation start point to be recorded? Can we rely on modern browsers to clone the window with a server hit, with which we can trigger a continuation? Will someone be able to spawn a billion continuations (and sessions) by hitting refresh? What about the back button? Arg!