Obsidian                     
Next Generation Lightweight Application Infrastructure Software

 
           
     

TECHNICAL DETAILS

 
     
     
  REQUIREMENTS (Informal)   DESIGN (Informal)    IMPLEMENTATION
         
Usability
(from the point of view of the application using Obsidian)
       
         
Usability implies simplicity and useful functionality        
         
  REQUIREMENT
  Simplicity
    DESIGN
  Simplicity
    IMPLEMENTATION
  Simplicity
         

Simplicity implies a reasonable size (so the system can be understood) and well understood responsibilities (so that everybody knows what to do with what they understood). We can go further and realize that simplicity implies the minimizing the amount of knowledge about the system required to add a given feature.

 

Reasonable Size
The less code there is, the less design there is, the less there is to fuck up.

The goal is to implement the entire framework in 10,000 lines of code or less including class and method comments.

Maintaining a reasonable size means throwing a lot of functionality over the wall into plugin services. So even though the system is to have much of the XAML functionality, it will be provided by plugins - which adds flexibility and reduces complexity - and keeps portability and universality of the XML targeted at the frame work if the plugins required by the XML are specified in the XML and locatable by the framework.

Well Understood Responsibilities
Whether the responsibilities are well understood is, of course, a judgment call made by each user of the framework - but making sure that the areas of responsibility are few in number can only but help.

 

Minimal Knowledge Required
All application functionality will be provided using plugins (i.e. delegate any special needs of the application, which adds complexity, to the application or 3rd party tools).

All application data is managed and provided by the framework. It is the User's data, after all, an application just needs to work with it at the user's bequest - let the framework manage getting it to and from the application to wherever else the user wants to send it. This is a key feature gained from think about how Unix command line shells work and why they were/were not so successful.

Both of these also minimize the need for exposing and super-generalizing class methods in order to support inheritance unlike most other framework designs.

Declarative XML as the specification of application functionality has been proven to lower the entry barrier to using a set of features.

Basic MVC (Model - View - Controller) design transmogrified into a DSC (generic Data - Service - Controller) design

Services - All services are dynamically loaded plugins which read and write data. This data is persistent and may be defining or displayed in the GUI. It is not clear yet whether all services should keep volatile data in the system, or whether they can store volatile state locally.

Data - All data is persistent, highly-typed and referenced internally by URI. This creates data that more closely mimics the real world - and it is expected that any limitations with this system will be performance related. Features like partial loading of super large data structures and session management become extremely simple with this design.

Controller - Not really a controller in the MVC sense, this is almost completely free of intelligence, and mostly manages the adding and removal of its services and dispatching of service requests. Large numbers of event- and change-driven bindings which are created by the plugins during initialization and during activity might also be considered as part of the controller layer.

   
         
  REQUIREMENT
  Useful Functionality
    DESIGN
  Useful Functionality
    IMPLEMENTATION
  Useful Functionality
         

This is somewhat of a judgment call based on the initial applications envisioned by the author of the framework - but useful functionally in general seems to consist of:

       
         
  REQUIREMENT
  Automatic Persistence
    DESIGN
 
Automatic Persistence
    IMPLEMENTATION
 
Automatic Persistence
         

The real world is persistent, one does not have to 'save their changes', nor would it be advantageous if we had to. The format of the persisted data is unspecified.

A corollary to this is that there must be a robust undo and version management/recall system so that mistakes, when made and persisted, can be reversed.

 

The approach taken is to make the general data structures persistent by default. Because most of the content represented by these general data structures needs to be persisted anyway - configurations, user profiles, application data, and so on - this is a win-win situation.

   
         
  REQUIREMENT
  100% Undo/Redo
    DESIGN
 
100% Undo/Redo
    IMPLEMENTATION
 
100% Undo/Redo
         

It would be great to have undo (do-overs) in the real world; this allows a user to explore possibilities in the application space much more freely with permission to make mistakes.

There also needs to be an ability to mark versions and to retrieve them and their undo history.

       
         
  REQUIREMENT
  Transactional
    DESIGN
 
Transactional
    IMPLEMENTATION
 
Transactional
         
100% fail-safe/fault-recoverable data manipulation is the goal.  

The approach taken is to make the general data structures persistent by default. Because most of the content represented by these general data structures needs to be persisted anyway - configurations, user profiles, application data, and so on - this is a win-win situation.

 

   
         
  REQUIREMENT
  Traceable
    DESIGN
 
Traceable
    IMPLEMENTATION
 
Traceable
         

Extensive tracing and debugging support is required and should fit in to the core framework given its streamlined and constrained design.

Logging support will be provided by plugins external the the core framework.

       
         
  REQUIREMENT
  Fault Detection, Isolation
  & Tolerance
    DESIGN
 
Fault Detection, Isolation
  & Tolerance
    IMPLEMENTATION
 
Fault Detection, Isolation
  & Tolerance
         
The ability to detect which providers and plug-ins are consistently failing - and, if possible, suggest or automatically install alternatives.        
         
  REQUIREMENT
  Semantic Validation
    DESIGN
 
Semantic Validation
    IMPLEMENTATION
 
Semantic Validation
         
Easy declarative and pluggable semantic validation.  

The approach taken is to support Pluggable and Declarative Validation:

Highly-typed and validated properties - properties not only know their type and name, but minimum and maximum values and many other, pluggable constraints can be specified.

Highly-typed and validated data sets - relationships between properties and many other, pluggable constraints can be specified.

 

   
         
  REQUIREMENT
  Automatically
  Generateable
  User Interfaces
    DESIGN
 
Automatically
  Generateable
  User Interfaces
    IMPLEMENTATION
  Automatically
  Generateable
  User Interfaces
         
         
         
  REQUIREMENT
  Testability
    DESIGN
 
Testability
    IMPLEMENTATION
 
Testability
         

The system needs to be testable. This means virtual user testing - the ability to automatically test the applications written using Obsidian as if a million users were using it.

This does not mean unit testing - though unit testing is included because it is so easy to do with largely self-describing APIs like Obsidian has. Unit testing tests a functional unit, it does not test the veracity and appropriateness of the unit as to whether it is doing what its callers expect it to be doing. It is all fine and good to make the unit handle values it will never receive - assuming one has the extra time to do so - but this does not help achieve a bug-free application.

       
         
         
 
       
       
       
 

Contact Us



Copyright © 2005 Software Farm, Inc.