« Cat, Icons, and MaxDB | Main | Failure »
September 29, 2004
Application Servers
I wonder if the concept of application server is also bunk. Plone appears to be Zope’s main excuse for existence these days—and I have serious difficulty discerning what it does from what Zope does based on the simple reading of the site.
For grins, I searched on Google for “open source application server,” then quickly realized what I really wanted to search for was “open source application server -java” to lose all the Java shit. I believe Java is fundamentally inefficient, as I may have mentioned before, because it was designed for the lowest common denominator of programmer.
I have narrowed down the search to these four rather strange app servers:
-
Based on a server-side JavaScript model, providing extremely tight PostgreSQL integration if you want it, or a template system that sits on top of it (if I understand correctly), it also uses XSLT for the display, which I’ve also mentioned recently I’m not very keen on.
-
Based on a strange but evidently cool language even I haven’t used called REBOL. It uses a snip/space metaphor which seems highly appropriate for designing a hypertext system.
-
OpenACS is built on AOL’s wacky but apparently now open source webserver, AOLServe. It’s scripted entirely in TCL, and integrated with PostgreSQL or Oracle, your choice. Unlike the others, it has been around for about 10 years and is billed as a really solid framework though a bitch to install. I wonder if this may be something like what I want.
-
This is some type of CMS which is wanting to fill the shoes of Access, so the developer says. So it seems to be a web-based system for making HTML reports and such on top of an SQL database backend (MySQL or PostgreSQL). Interesting, and very possibly nasty.
The only two things I’m certain of are that I am uncertain, and that this is no surprise to the readership. I am trying to diagnose the problem and I’ve come up with this:
- Versioning must be maintained at all times and be correct
- Content must be uniformly accessable whether it comes from the URL, the environment of the server, the server’s own variables, the filesystem, the database, or the Sky God for all I care (I will define uniform accessibility in a moment)
- The URL must be translated into something I’m calling an IRL, or Internal Resource Locator, by some mechanism that can be customized depending on any of the state information of the server, configuration, or the URL itself
- Content must be ownable, editable, and viewable with at least UNIX-style permissions applied, or possibly something more fun if it’s not terribly bad to implement
- I am wanting to separate the handler of a request from the output generator of a request, but I’m not sure it’s reasonable to do this, or if it would be a serious gain for anyone, or if it would be trivial enough to implement that it is meaningless to spec it here.
- All of the objects and renderers in the system should be language-agnostic; I want to be able to use PHP, Ruby, and anything else as I see fit, preferrably without seeing a massive, CGI-like performance hit.
- Database abstraction may or may not be available, but it is fair to say that PostgreSQL or better will be required. Have little to no desire to complicate things with a lossy database abstraction that does away with concepts like foreign key and check constraints, multiple value primary keys, transactions, triggers, stored procedures, views or replication. I want the system to be flexible enough to find content just on the filesystem, but if a database is going to be involved, I want solid gold not semi-relational crap. (Did you know that SQLite is closer to a RDBMS than MySQL? It has views, transactions and foreign keys, just not actually valid types.)
My urge was to revisit struts and phrame to see if I can understand the whole MVC2 idea better. I like the idea, but it seems clear that if you need a degree to understand the config file, and everything else is magic that happens behind the scenes, there will be great confusion. I am sure it’s great, but I haven’t heard a good explanation of it that made sense yet, so I think I will continue to muddle around in the slime with the other piglets that think that what really happens during an HTTP transaction is this:
- A request is sent, essentially encapsulated in the URL + POST + headers
- Somebody on the server gets slapped awake and handed the request
- Sleepy moron scrambles some sort of text together and sloppily hands it back to the requester
The desktop application analogy isn’t very analogous, in my opinion, because you get to keep state (for what it’s worth). So I’m not entirely sure if something as complex as MVC2 is really warranted, because I don’t really have a strong desire to make web applications as complex or more than desktop apps. But I worry if a loss of generality at any stage is really justifiable.
For the record, in the “maybe someday might exist” “application server” I describe above, the only part that makes sense to me right now is the URL part.
In unrelated news, I think this weekend I may attempt to install PostgreSQL with Slony-I on a big stack of TCC computers and then hammer it, and then kill some of the instances, and see how it works and if a simple CGI for failover host detection is as easy as I suspect it is. I have two boxes here, someday they’ll both be on the network, but for right now it would probably be a hassle to set it up. I’m looking forward to discovering that Slony-I is the answer to most of my PostgreSQL prayers, but I have a few reservations and some general nervousness. We shall see.
Posted by FusionGyro at September 29, 2004 11:30 PM
Trackback Pings
TrackBack URL for this entry:
http://www.clanspum.net/~fusion/blog/admin/mt-tb.cgi/25
Comments
Just to clarify comments on Whitebeam - we don’t use XSLT as part of the architecture. Obviously you can use stylesheets client side if you want but I think XSLT is a fundamentally limited and inefficient system.
I don’t like Java either :-)
Posted by: Peter Wilson at May 12, 2005 11:18 PM