Good documentation is a battle between telling a memorable fable and overloading people with detail.

I’ve sat down and drawn another diagram (see below) of the MetaWrap rendering pipeline as I’m still in the process of mulling over the design.

I was inspired by the drawing style in this article to have tried and re-describe the pipeline in terms of traditional layers but relate in another axis the logical elements of the pipeline.

I’m looking for the perfect diagram that captures the concept accurately without being overly detailed. What I have now is still flawed, but I think I am getting there.

First a brain-dump of where I was, where I am now and where I am going.

The purpose of the MetaWrap rendering pipeline is to provide a client side framework for web application development in the MetaWrap platform. I built a working prototype 5 years ago, and this is a refinement of that prototype. A lot more processing power is available now and I can and will take the original idea much further.

• Applications developed within MetaWrap framework can be easily remixed (see GreaseMonkey ). The rendering pipeline provides access to raw XML data as well as the final HTML output, so you can remix the data, the UI or both at the same time.
• Applications can be easily re-skinned.
• Applications can be easily transcoded into other platforms. eg. XHTML, CHTML, WAP

All of this can be done at the whim of the consumer of the application.

Thats the aim anyway 🙂

The input of the rendering pipeline is XSLT and XML which all originate from a MetaWrap server.

The output of the rendering pipeline is CSS, HTML, JS and XML.

A web browser gets the XSLT and XML out of the MetaWrap server via a HTTP request to an Apache web server running a module that implements the MetaWrap HTTP Gateway. The MetaWrap Apache module connects to a MetaWrap server. The XML and XSLT is obtained by fetching and translating objects from the MetaWrap server.

The rendering pipeline excutes within the MetaWrap Apache module and JavaScript libraries. I have a mostly working prototype of the pipeline in the following test case here.

If the browser is not capable or fails during any stage of the rendering pipeline, that stage can be substituted by the Apache module.

When a browser makes a request against the MetaWrap Apache module, the URL is translated and mapped into an object of focus. A focus can be anything from a single string to a full application. Via the focus, appropriate XML and XSLT can be generated. Via the consumers user context, customised behaviors can be loaded.

In the best case scenario, the browser simply takes XML and XSLT and execute the whole pipeline in JavaScript.

In the worst case scenario, a braindead or buggy browser simply takes XML, HTML, CSS and JS from the Apache Module.

Why do it this way?

XML data, XML behaviors and XSLT can be cached, saving a large proportion of the traffic from the web server for most applications.

The processing associated with rendering layout can be moved from the server to the client which prevents your server from burning a hole through the floor.

An application server essentially becomes an API that is accessed via XML over HTTP and a database of styles and behaviors to associate with and application and user.