Frameworked Up

I've been spending a lot of time discussing my new development framework with other web application developers, garnering their feedback and integrating it into a whole new design pattern that solves a lot of the problems associated with MVC.

Two of the main bottlenecks with any MVC framework are:

• Memory bloat in the controller
• IO operations on the view when rendering

One of the tenants of an MVC design is that your data gets loaded by a controller function and sits there until the view renders it as a page. These are usually a bunch of fairly-heavy state-aware active record objects. This is all fine in most cases, but if you're worried about memory utilization and performance you'll realize that it can quickly get out of hand.

What I've opted for, instead, is to develop a framework based on XML-RPC. Each URL represents an API end-point that returns pure XML. Since the objects aren't having to sit in memory for rendering later, they can be immediately removed upon spitting out its XML response. 

Since XML responses aren't particularly useful to humans, each response includes a reference to its XSL stylesheet. The XSL stylesheet allows the browser to take the data returned as XML and render it as a DOM view. Your users' web browser does all the heavy lifting and you bypass all those expensive string operations that most template libraries use. 

XSL is supported in every modern browser. However, with a simple .htaccess file you can instruct the server to render the XSL and the XML into an HTML document for any browser or search engine that doesn't natively support it. Win!

Prefer JSON-RPC/JSONP/REST? It supports pretty much anything you want. Currently, my standards compliance could use a little more tweaking to conform to spec, but it's well on its way to being a flexible API framework. Since every response is merely XML, it makes a great back-end to web applications using AJAX.

What's this all mean? Well, it means you write a back-end API once that's made seamlessly available over XML-REST/XML-RPC/JSON-RPC/JSON-REST/JSONP and have it all render down to HTML for people accessing it via a browser. Amazing!

For the sake of providing a demonstration, I'm giving a link here to a early technical proof-of-concept:

http://xml-rpc.xombo.com/

When you load up the main page it shows you a description of the classes available to make requests to.

You can click any class which opens its own description.

Any of the links in an class description represent a function within the class. 

The most easy one to see in use is the "update" function, as it will show you what an automatically generated form looks like and allow you to submit it to the database.

Because I used jQuery Mobile to create a simple UI, some requests are "forced" to load as XHTML so that they render correctly with its animated transitions. But, with some tweaking to the URL you can easily pull up the source and see that it's all just an XML response with a stylesheet attached.

Update: The Daily WTF posts a rebuttal. 

Boot to Gecko and User Sovereignty

I've been doing a great deal of research on an open source company whose products I've long since used, Mozilla.

Lately, Mitchell Baker has been writing about a shift in Mozilla's focus to extend well beyond the browser. Her essays reflect an urge to move into the sphere being explored by Google's Chrome OS and Palm's Web OS.

Web browsers, despite early contention in the marketplace and the courts, have become a utility--in the economic sense of the word. A web browser is now as essential as water, sewer, and electricity. Furthermore, there's no interest left in competing over price because margins are already dangerously low (if not non-existant). The standards are as well defined as they are supported and there's little room to push new standards upon other vendors.

Ultimately, what can differentiate Mozilla in this sphere is its dedication to what Mitchell calls "User Sovereignty." Instead of having to put your trust in a number of 3rd party for-profit entities, maybe Mozilla can envision a world of web services that put privacy and data ownership back into the hands of the creators. This is similar to the work I've been doing with XOMBO, to establish an enterprise web desktop powered by a "cloud" that can be hosted yourself.

This means that Mozilla must expand its mission into developing web server software and increasingly comprehensive developer frameworks on both the client and server sides of the equation. Luckily, they have a background in developing web servers thanks to the lineage inherited from Netscape Communications, Inc. However, there's still a significant gap between having a web server and developing interfaces (XML-RPC, JSON-RPC, REST, SOAP, etc...) to work with the next generation of browser-based applications. Where W3C is able to define and perfect standards in an objective way, Mozilla is poised to create the tools that embrace those standards and make them available to all developers. Powerful standards-compliant tools will breed a whole new generation of web applications and make it even easier for developers to get started using the latest technologies.

The mission of Microsoft's Technical Evangelist team.

Conventional wisdom says the competition is fierce. I recently had the experience of installing Microsoft's .NET development toolkit for web developers, which they now offer for free. This experience has lead me to believe that Mozilla doesn't have to reach very high to lift themselves beyond what Microsoft has achieved. But they shouldn't stop there.

Mozilla's installation base, brand recognition, and cross-platform support make it a virtual "no brainer" for anyone looking to build applications--the same desires Microsoft expressed in their technical evangelist slideshow.

Now that we've established the multiple layers Mozilla must be set out to bake into their cake, they simply need a compelling application to act as its icing. I believe that Mozilla's target should be to create an open source, distributed search engine. With their agreement with Google presumably coming to its contractual end this year, Mozilla needs an alternative and unbiased search engine that they can use to generate additional traffic-based revenue (ads).

In the end, if my interpretation is right, Mozilla could be set out to compete with some of the largest players in the market by creating an open source alternative. With Microsoft, Google, and Apple in their sights, will Mozilla be able to extend itself well beyond what was achieved with Netscape in the "portal" boom of the late `90's? Time will tell, but I believe that Mozilla is the only public-benefit organization equipped to take on the challenge.

No virus found in this blog post.

No virus found in this message.

You're probably familiar with the notifications that anti-virus programs put in e-mails letting you know that the e-mail has been scanned and is considered "safe" to open.

It's unfortunate that this is common practice with so many anti-virus applications. I can understand why they do this, but ultimately it makes the recipients of these e-mails less safe because it gives them a false sense of security.

Anti-virus publishers do this because it gives them an opportunity to advertise their product in every e-mail you send, at no expense to them. However, since there's no mechanism for the recipient of the message to test the validity of the notification, it does nothing to enhance security.

There are many opportunities between the sender and the recipient to inject malicious code into an attachment. The notification could be faked by simply pasting it into the message manually or by the tricks of a malicious program.

If people receiving these messages falsely believe that the notification is affording them security, because of these precautions taken by the sender, then they may open a malicious piece of code thinking it is safe.

I would encourage anti-virus publishers to make it clear in their notifications that it is simply a banner ad and affords the recipient no added security. If your anti-virus application allows you to disable the banners, I would suggest disabling it.

The best way to be safe is to use an e-mail hosting service that performs virus checking prior to you downloading your mailbox. This can also be accomplished in self-hosted environments using a number of open-source tools which are compatible with popular e-mail servers. Additionally, it's advisable to use a virus scanner on your local machine. ClamAV is a popular, multi-platform, open-source anti-virus program. Finally, it's never advisable to run executable files (programs, screensavers, batch files, etc.) that you receive as an e-mail attachment regardless of how protected you are.