ABRA Design Principles

• The program should serve the users and the data, not the other way around. We try to allow users maximum flexibility and choice of interface; we try to store or export our data in standard formats and allow users direct access to it as much as possible for stability.
• We are one small entity in a chaotic world; we don't control most of the world. We try to be a friendly entity that knows a little bit about other entities - how to link to them, how to talk to them, sometimes how to run them. We are extensible and welcome plug-ins for protocols, data formats, etc.
• Design is roughly in three layers:

  		Presentation - Templates - Scripts
  		Rules, Structure of Data
  		Modular general-use routines for accessing data sources, etc
  

  The more that is on the bottom layer - modular, reusable, configurable - the better. But it is ok to hack on the top layer to make things work for a particular implementation, and later migrate the most useful bits into nice modules on the bottom layer.

ABRA Design Goals

Actual design...

Here is the top-level command loop. Its not the same thing that is running in the demo, though it will inherit a lot of the demo code..

abra.pl

Welcome - feedback, requests, suggestions for programming style and structure ;-)

CVS interface coming soon, I just got a new server and haven't got everything moved over yet..