Qwicap—the Java web development "framework" that advances the (apparently) unpopular idea that the structure of a web application should be no more dictated, or even affected, by sending a web page to a user and processing the resulting input than a conventional application is affected by reading from, or writing to, a file*—turned five years old today.
Work on it began June 4th, 2003 while I was a member of U.T. Austin's Networking group, and the first plausibly complete version (1.0) was ready four months later, on September 30, 2003. It was open-sourced a little less than three years later, in August of 2005, with the release of version 1.3. The current version, as of last Friday, is 1.4b25. (Work on 1.4 has been ongoing since the beginning of 2006, which makes it a fine example of setting too many goals for one release of a product. I anticipate declaring it finished as soon as there's time to give its multi-lingual features a good workout.)
From the start, Qwicap's development was driven by the goals of simplicity, security and standards-compliance. I believe it has proved that those are not opposing concerns, as it delivers first-rate intrinsic security, by far the simplest development experience of any Java web framework I've seen, and compliance with all relevant IETF and W3C standards. The design decisions that followed from those goals, especially the simplicity, mean that Qwicap will never be suitable for developing, say, the web interface for Bank of America, but they make it a very good choice for developing the hundreds of much smaller web applications that most large organizations use internally, or to serve other relatively small user communities.
* Blocking is Good
It'd be an enormous pain in the ass if conventional applications had to exit after every read or write operation they performed, and then start over from scratch when they were later notified that the read or write had completed. (That description may sound somewhat similar to asynchronous I/O, but even that doesn't require the application to exit between I/O operations.) For some reason, however, it is commonly accepted that web applications should have to operate in exactly that manner, if you understand the writes to be equivalent to sending web pages to users, and reads to be equivalent to acquiring the input produced by those web pages.
Why have web application developers been willing to have such an absurd burden dumped in their laps? The fact that many of us started by writing CGIs may have something to do with it, but that was a long time ago – there's been ample time to reconsider the CGI structure since then. Scalability is probably one reason, but what percentage of the web applications developed in the world really need to scale to thousands of concurrent users? My belief is that it's a small percentage, and that the tools suited to high scalability aren't ideal for smaller apps. HTTP's statelessness may be another reason for believing that it's appropriate to process each hit in isolation, but how many web applications are, or can be, truly stateless? Reality is inherently state-rich and I don't believe that most web applications can really get away from that, nor do I believe that it's generally worth trying to do so.
Qwicap was, and is, my response to that absurd burden. Its most basic principle is that sending a web page to a user and obtaining the resulting input should be a blocking operation – the application should simply halt after sending a web page, and it should resume exactly where it left off when the user's input from that page arrives. Not so much as a local variable should be disturbed in the process. It shouldn't be any different from the blocking that automatically occurs when a program reads from, or writes to, a file or stream.
Of course, for some purposes, blocking I/O isn't the most efficient approach to I/O, but it is the hands down winner for most applications. I imagine that most developers have never done anything other than blocking I/O. By the same token, I believe that most web application developers should never have to do anything other than blocking user interaction. Qwicap makes that possible. Therefore, a Qwicap web application is not only a set of plain-old-Java-objects (POJO), but is also a plain-old-application that begins execution at its "main" method, interacts with the user when it needs to, and exits when it has accomplished its purpose. It'd be hard to make things any simpler than that.
Nonetheless, gentle reader, you'll have noticed that Qwicap has not taken the industry by storm. I don't think the industry is even aware of it. Well, I've never been any damn good at self-promotion (I really hate the idea, in fact, and I don't even like writing this post), so Qwicap's obscurity is, perhaps, unsurprising. But, if any of the above struck a chord with you, take a look at Qwicap, and let me know how it goes. (What works? What doesn't? What do you find yourself doing repeatedly or clumsily that Qwicap might simplify or even handle for you?) Over the years, I've incorporated a lot of feedback from local developers into Qwicap's design and/or API, and I remain interested in incorporating more developer feedback, where possible.
Posts
