The Mono Common Language Runtime as a crux of combinatorial Free / Open-Source Software Lifecycles


Please allow me to preface this entire writing with one thing:


    I HATE PHP.

I learned PHP, originally Personal Home Page, now "Hypertext Preprocessor" when I was in high school and thought it was very nifty - indeed, it was a great open-source version of the parlance of the web at the time, things like ASP and CFM which evolved from Server-Side Includes (SSI), allowed you to jam some code into your HTML which would be executed on the server and then could manipulate images, compress or uncompress data, execute shell commands, and connect to database for a multitude of reasons.  I hope it's obvious to most people who call themselves professionals that this model is the architectural equivalent of the entire Intarweb marveling at its' navel.

I digress.

So, I develop web applications, but sometimes they are "distributed applications" using "web technologies", and sometimes I want to throw some web-ness away in favor of a UDP protocol or something.  As a developer, I want to have to change only a minimal amount of code to un-web an application, so a few years ago I began to embrace the common Model-View-Controller pattern set out in smalltalk and catalogued by the GOF.  MVC is great, and in following years I have come to know a number of other useful patterns which can interact with a system this flexible.

One problem I run into is that when interfacing with an existing group of developers who have their own tool preferences, a lot of time is wasted selling them on my development methodologies which may be able to happen by osmosis if they could continue using their own tools to interact with systems I build for them.  This is a big pain, because I don't want to support PHP, and without knowing or understanding it, PHP developers could inherit a ton of advantages from my tools simply by means of the lower portion of the stack being constructed on my end.

In parallel with this concern is an ongoing drive to improve some of the internals of Python, the interpreted OO language that I use for most of my development, and convincing this subcommunity to adopt simple, established ideas about generic computing problems is more of a chore than it is often worth.  So, we end up with terms like "Pythonic" which describe a way of doing things which is, in some regard, Right(tm), and somehow doesn't disturb the force wrt to the weaknesses of Python.

So, after much research into esp. garbage collection algorithms, threading and other concurrency models, and optimization of dynamic multiple inheritance / polymorphism in languages and environments like Python, I came to a simple decision:

  .NET, even if conceived by Microsoft, was designed to solve exactly the problem I am having.

For once, to some small extent, some engineers in Redmond have done something at least semi-right, as far as I can tell, and that is to create a generic environment for executing code which can be written in any language, but using many of the same concepts.  As I strive even to find better solutions for problems above Python, in frameworks like Zope, Archetypes, and Plone, I find that .NET, or more properly, the Common Language Runtime, already provides services of the same caliber.  In fact, I'm pretty sure that Java and/or J2EE do as well, and I started thinking about the Zope style of development as a means of developing applications which can be deployed alongside existing apps.

In my quest to find documentation for the interface lookup APIs, I stumbled on a bunch of things I hadn't heard or thought about in a long time, like PHP.NET, and this made me think about mashing a python, zope/archetypes-style namespace up against a dumb php page, solving a major dichotomy we had at Rackspace:

  * Designers and new team members were more comfortable in PHP, and this is where many quick-n-dirty solutions came from..

  * Even in PHP, we wanted to design things in an object-oriented manner, but even with PHP5 we didn't have anything as flexible as Python, and certainly nothing approaching Zope or Plone/Archetypes as a framework.

In fact, there was a case where a PHP developer used our Python APIs to build himself an XML-RPC server, connect to it from PHP, and avoid having much complexity underneath his HTML design at all.  Unfortunately, the overhead made this perform horribly, but the architecture is good, and I think it may be possible to achieve it using the ECMA CLR / "Microsoft .NET" environment.

Add to this a few interesting facts:


I think it may be possible to make Plone 3.5 or so run outside of Zope, still using a lot of code from Zope - esp the publisher, perhaps merging security with twisted.cred, using Mono, the open-source, .NET-compatible, CLR implementation.

So What?

Good Point.  Well, I hope for this to continue addressing some issues:


However, there are some new issues on the table:


I think this will take a long time, but has good chance of success, esp if I can get some customers on-board with wanting to see this happen, sponsoring and/or hosting sprints and core development, and/or even just supporting my business enough for me to spend some time on this sort of project.