Introduction to UnixObjects

Definition

UnixObjects (UO) is a software architecture for Unix systems.

“Unix” includes GNU/Linux, Mac OS X, NetBSD, HP-UX, IBM AIX, Sun Solaris, and many others. Basically all those operating systems derived from or inspired by the Research Unix systems of the 1970s.

UO is a set of documentation specifying, recommending and suggesting practices to follow in the development, organization and identification of software components. UO also introduces a new text-based container file format, an object-oriented path resolution algorithm and a standard shell-level command to access it.

Benefits

UO takes a quantum leap in the abstraction level of programming—the biggest the software industry has seen in over 30 years. This can bring exponential gains to programmer productivity. UO is particularly good at making use of existing executable programs and turning them into methods in a coherent object system. This makes ultra rapid prototyping possible.

UO is agnostic about implementation languages and development tools, allowing components developed at different times using different techniques to seamlessly integrate. This contributes to a smooth evolution from a prototype to a production system and in the life of the production system.

Ideas

UO can be seen as a mergence of two successful ideas from the past: the Unix tool approach and object-orientation. There have been some earlier attempts at this but none that have as thoroughly disassociated the model from the implementation and stayed true to the Unix philosophy.

UO also has some resemblance to the Self programming language, with a similar dynamic inheritance model and overall conceptual simplicity.

New ideas in UO include:

• transparency of file executability,
• a new pathname decomposition model,
• prototypes and shared objects for Unix,
• replacement of the PATH environment variable by a parent link,
• extension of the Unix name space to cater for “virtual objects,”
• and several others ...

History

The research for UO first started in the mid 1990s. The author was unhappy with the existing object-oriented programming languages: it seemed either the whole paradigm was at fault, or no one had yet figured out how to get the full promised benefit out of it.

The original application for UO was sound processing^[1]. This application area happens to have the somewhat contradictory requirements of (1) complete dynamism on component arrangement, including distribution of the task to any number of computers; and (2) highly optimized performance.  And considering that added to this is the requirement for the support of complex meshes with signal feedback between any two nodes, it soon became clear that by figuring out how to solve this problem one would have a programming environment capable of handling pretty much any other computing task as well.

Between 1995–2002, several different designs were tried. The somewhat surprising discovery made from these experiments was that any attempt at optimizing performance in how signal processing components would be coupled together (in order to form processing pipelines and meshes) would ultimately end up both complicating matters and degrading performance. The reason for this is that there are natural opportunities at simplification and optimization that can only be discovered at connection time in the nodes. Whereas any externally mandated protocol would in too many cases turn out to be a hindrance to this.

The ultimate solution, UnixObjects, was arrived at in 2003. In this, the component connection layer is entirely abstract (with objects addressed by pathname-like ids) letting the components follow separately agreed upon conventions on—or even discover on the spot—how to talk to each other. Taking abstraction to the extreme removes the influence of the language on what types of connections and arrangements components can form. This makes it possible for the system to retain its highly dynamic nature and at the same time allows components to transparently optimize data paths and sub tasks to any degree desired. Examples of such optimizations include:

• negotiate data formats and exchange protocols between peers,
• cache signal processing results for repeated runs,
• recognize signal processing “idioms” among subnodes,
• perform on-the-fly compilation of themselves,
• pre-compute feedback samples,
• deploy an auxiliary signal processing device,
• etc.

all techniques that would normally be considered cumbersome but which become natural with UO.

Since 2003, UnixObjects has lived a life of its own, independent of its original, audio related, research context. It has been applied to such diverse fields as document processing, network management, financial accounting, data mining, personal information management and typography research.

The architecture was first published on www.timolehtinen.com on March 20, 2008.

Licensing and copyrights

You are free to implement the UnixObjects architecture in your software and distribute your software as you see fit. It would be nice if you acknowledged the inventor and linked to this website, but you do not have to do that if you don't want to.

You are not allowed to publish any of the documentation on this website. The main reason for this is that the UO documentation is still largely a work in progress. Eventually, I hope to relax this restriction for some of the content. When that happens this text will be amended accordingly.

This concept can succeed in promoting interoperability only if the meaning of the name “UnixObjects” remains unambiguous. For this reason, I ask that you not use it to identify your software. You can, however, say:

Product X supports the UnixObjects architecture.
Product X complies with the UnixObjects specification.

And indeed, I hope you do.