Random thoughts on web application internals

I've been playing lately with a lot of different ideas. Part of it is to further my own education, part of it is looking for good software design tips. Although there exist quite a few good applications or frameworks, both open source and closed, I can't recommend any as really flexible. By really flexible, I mean easy ways to change its behaviour, how it reacts to the outside world. Most frameworks and applications excell at being themselves, and are rarely excelling at being really good citizens, they are inward looking, as far as their configuration and query is concerned. These are bold statements. They are quite subjective and probably useless. I'll try to explain what I really mean by positive examples.

Most frameworks/apps, for example drupal do pay attention to the url queries. In drupal, it goes one step further than that simply assigning a few magic callbacks, it treats words as node, admin, term, etc... specially, each of them essentially being reserved words of a mini language. Without going into too much detail, I'm surprised, that nobody has mande the obvious next step - turn it into a proper mini language.

Similarly, webservices and their different incarnations - REST, XMLRPC, SOAP, .... (increasingly more complicated) dont go far enough. They reflect only the underlying architecture of an application. So far so good, but you can do only what the programmer or the sysadmin has decided for you upfront. No more. Whaat if you could do anything with the information exposed to you? Whithout any security compromises?

Wanting the freedom to explore the data or the knowledge built into a web application, calls for specialised languages.

Is a path an s-expression?

S-expressions, have been a not so closely kept secret of the LISP hacking community for more than 50 years. They are simple to parse and understand by both humans and machines. In fact LISP and Scheme programs are s-expresions.

A path like "/a/path/to/coding/heaven/or/hell" is easily transformed into an s-expression. Regardless if you take it like (a path to coding heaven or hell) or ((a path) to (coding (heaven or hell))
which in turn can mean a program. Actually the brackets are a simple and convenient, context independent way to denote grouping. By taking context into account, you can interpret a path as a mini-program.

basic computing with p-expressions

Let's say we have a minimal core to do computation is (as in abit modified lambda calculus) to have if, lambda, define, cons, car(head|first), cdr(tail|rest), constants, separators. Actually, initially I won't consider define, and the list operators. Defines can be done for us, and are just a handy shortcut to denote some binding. Similarly, although very useful, the list operators will be an overkill to consider in this case, and won't bring clarity.

Let's call path expressions p-expressions, resembling s-expression, but with context sensitive semantics.

As a first example, let's consider that we want to extract two particular nodes we know in advance from within a drupal website. The result format is irrelevant in this case, but can be plugged in. later.node/1/node/2 will look unfamiliar, but nearly obvious to most drupal users. If node is a predefined function, we say, give me results of node(1) and node(2). Similarly we could
lambda/node/*/if/has_tag/_/_/null
Translated into schemisish syntax
(let (y (lambda(x) (if (has-tag? x) x 'null))) (y (node any_node)))
In php-like lingo it would be something like:
foreach($node as $key=$value)
{
if( has_tag($value) ) display($value);
}

Having higer level functions in available for interpreted p-expressions gives power, unavailable currently. Yes, it will probably be slow. But the majority of the queries won't be that complex anyway. For really complicated stuff, like content filtering, you would probably have some higher level functions anyway, but their combination is gives power to the user beyound anything I currently know of.

Mix and match

To return an RSS2.) feed
rss2.0/node/1/node/2
Atom
atom/node/1/node/2
a restful html-chunk for embedding in another website, not the full bodied version
html/partial/node/1/node/2
dream on

Powered by Drupal, an open source content management system