CM: THE NEXT GENERATION - Building Reliable Applications

modes saying "create if and otherwise open" or vice versa. I don't have to do different read
operations for text and binary data using the same functions.  That's all taken care of and implicit in the calls I use.  Even more to the point, the functions are easy for anyone to pick up, and make for clearer code reading.  OK, there are a few good file system APIs out there, but it's just that the universal ones seem to prefer assembly language level usability.  And I don't mind having the ability to do raw IO on devices.  But please don't impose that level on everyone!

Having our own API also allows us to easily add functionality to our file system, such
as using "> []" to redirect output to a window. And, it provides a nice re-usable module which is portable across platforms (by design). 

We know when we start a major project that we'll need to: access the file system, have
a database, deal with storage allocation issues, etc.  So we start by ensuring we have the
"best" APIs for these functions - APIs that are easy to use and which are highly functional.  And because they're re-usable, we benefit more than once.  Not only do we have these advanced, portable modules ready for any project, but the reliability of them has already been tested out on other projects.

We don't stop with a few module APIs, we go much further.  For example, at Neuma we have modules for command line interpreters, name directories, database query languages, macro definition and substitution, networking, GUI generation, and many more.  Most of these were largely developed in the 1980's and 1990's, but they still evolve to support, for example, new GUI architecture advances.  After a couple of decades, they have become very stable and very reliable. 

In effect, generating these libraries of re-usable APIs allows us to build new
applications very rapidly.  We're basically using a very high level language - even beyond that of a Perl or Visual Basic.  And that's our goal, to keep making it easier to build new applications, even to the point of exporting this capability to the run-time environment.

A Glimpse Inside Neuma

So how does Neuma do design?  Or better yet, how did Neuma build a "reliable" CM product?  What did we do right and what did we do wrong?

First, we decided to address areas where we were very strong.  These were primarily Database and Configuration Management, where I as founder had had over a dozen years of experience in helping to architect a couple of major Telecom products which
were highly successful.  Even before we decided to focus on CM, Neuma began building a Next Generation Database (NGDB) because we saw a need for it in the market-place and we were good at doing it.  We especially saw a need for a small-IT database.

We focused, as we did in the telecom industry where 4 hours down time in 40 years
is acceptable, on reliability.  Reliability has to be planned into a system, by keeping it simple, and by minimizing the dependence of complex or non-universal OS platform features.  We built our own platform-independant APIs and ensured that they did what they were supposed to do on all platforms.  And we made sure that the APIs were easy for
developers to use.  We paid attention to the order, the types and the naming of parameters.

Having had years of experience in compiler design, database design, operating system
design and configuration management design, we started with a number of design
guidelines - you know, like don't use goto's when coding.  But more extensive than this.  Like paying attention to how to design each function of an API - whether to have one function with a lot of options or several functions with few options, or both, and in