In general, the quality of software is critically dependent on the skill with which the problem has been abstracted. A poor abstraction will leave many exceptions and a lot of extra error prone code. Conversely, a good expression of the problem will handle most cases as normal and will be relatively easy to modify in the light of new requirements. The design of a programmable solution to a real life problem is the key skill for IT and it depends far more on clear thinking than anything else.

Martin Brampton

ARGON is an attempt to design a next generation computing platform. By computing platform, I mean both an operating system, or a platform like Java that sits atop an existing operating system, but appearing the same to the software running on top.

The design process has been simple: I have studied every applicable field of computing as best I can, learning the pros and cons of existing systems, studying even the most exotic theoretical solutions to a problem. Then I have tried my best to find the best combination of technologies to solve the problem at hand: To build a platform upon which the highest possible quality of software can be constructed with the least effort.

Overall design

For reasons of scalability and fault tolerance, clusters of nodes are clearly the future of server-side processing, and the same model has benefits for other areas such as embedded or personal computing. So an ARGON system is a cluster, composed of one or more nodes. Generally, the cluster as a whole is managed as a single unit, with the absolute minimum of per-node administration. For various reasons it is possible to reduce the set of roles a given node performs in the cluster, but the cluster endeavours to be fault-tolerant and scalable by automatically allocating work amongst the available nodes that can perform that work. The hard part of that goal is, of course, managing state, which we do by replicating state onto more than one node, while distributing state amongst the nodes to spread the load. So an ARGON cluster may be considered as a giant replicated distributed fault-tolerant centrally-managed database, with the entities in the database organised into a directory for human browsing and identification by a symbolic name. These entities combine code and data, since code is stored alongside data in the database, with ARGON providing a portable runtime environment for code to execute on arbitrary nodes. The native means of accessing ARGON services is via ARGON's own network protocol, MERCURY, which provides authentication, access control, encryption, load balancing and fault tolerance (through recognition of the fact that entities are hosted on clusters, not nodes). However, the legacy adapter layer provides industry-standard interfaces on nodes that are configured to support it: HTTP, SMTP, CORBA, and so on, all mapping from their respective domains into the entities within the system, while (in the other direction) mapping the external worlds of the Web and legacy CORBA/DCOM/RMI/etc. services as virtual entities.

On top of that fundamental distributed computational core, I then define higher-level architectures for user interfacing and other standard operations.

The result is an integrated architecture for computation ranging from hand-held devices through embedded control systems and laptop/desktop workstations up to the Big Iron in datacentres.

Current Status

Vapourware! I'm still finishing off the designs for most of ARGON. However, I have actually implemented a few experimental prototypes of HYDROGEN...

My approach to development is thus: This web site aims to explain the concepts involved, emphasising readability above all. I have a private file of notes which I dump thoughts directly into, and I'm also writing up formal specifications of areas of the design which I feel are completed.

Most parts of the design are in flux; the flux lessens as I home in upon a good solution, until I find a design that sparkles like a jewel, with that inner purity one finds in a truly fundamental abstraction. That's the point at which I start to write up a formal spec for that component!

I will not permit inconsistency in my specs, so I am careful about what point I start to solidify a design to that level in order to avoid the horrendous effort of rewriting existing specifications and having to comb everything to find dependencies to update. My private notes, on the other hand, are written tersely to avoid interdependency between areas (at the cost of being rather incomprehensible unless you're already familiar with the whole thing).

This site, however, is full of waffling prose about things, with lots of explanation of interrelationships between components, which means that it's also prone to inconsistency and being the least frequently updated reference of them all...

However, with the most important parts of the (now mercifully simple) IRON formal spec completed and the HYDROGEN spec firming up, I hope to release some of those soon!

There's an email list for discussion: Visit http://lists.warhead.org.uk/mailman/listinfo/argon to sign up.