Introduction to CAVOR and an Overview of Components

Introduction

This is to provide a quick guide to the various pieces -- components -- that make up Cavor. Note that I'm using "component" here in a more generic sense than is used in specific component software models like CORBA, but rather as a general term to include libraries and programs that together make up Cavor but may also be used independently of Cavor.

Cavor is a tool designed to be customized. As a comparison, consider a spreadsheet program. Out of the box, a spreadsheet is basically just a blank table that lets you fill in the boxes. Big deal. It's only when you start to customize a particular spreadsheet 'document' -- add formulas, link cells together, adjust the size and format of cells -- that it really becomes interesting. Of course, most spreadsheet packages come with sample spreadsheets to get you started.

Similarly, Cavor is, out of the box, just a program that ties vector graphics diagrams to data stored in a database. It gets more interesting when you start to customize it -- add tables for attributes of things in the diagram, customize the appearance of lines and symbols in the diagram, add logic performing calculations based on those attributes or controlling the display based on user input or queries. This sort of customization leads to applications ranging from simple vector drawing programs through diagrammatic tools like UML (Unified Modeling Language) and other software design aids; CAD applications such as drafting floor plans or designing electronic circuits; to GIS (Geographic Information Systems) applications such as mapping, outside plant facilities management (ie, asset management and network design for utilities such as telephone, electric, water, etc.), and so on.

Of course, Cavor only provides a basic core on which to build such applications (although there should be some simple samples available as a guide.) And I don't claim that Cavor is ideally suited to all such applications -- just as you'd more likely buy a tax software package to help you do you income tax returns rather than customizing a spreadsheet, it may be that some other custom-built package suits your needs better than adapting Cavor would. (And of course, since Cavor is free software, there is no warranty anyway.) Think of Cavor as a "swiss army knife", a handy set of tools to have around to do a "not too shabby" job in a number of different areas. In many cases, that will be good enough.

What follows, then, is a list of the tools in that box, er, swiss army knife. For more details look for individual documents on each component. (Of course, as of this writing (October 2000) many of these components are in crude or nonexistent state. Check the web page for updates.)

Some of the larger components are in turn made up of smaller pieces that may or may not be useful on their own, but in any case help better understand the overall workings of Cavor. Noted in italics is the status of each as of this writing.

Strictly speaking, this isn't a Cavor component because we don't supply one of our own. Rather the intent is to let Cavor use whatever RDBMS the user already has available or can easily obtain. There are certain minimum requirements, of course, and there's no guarantee that a port to a particular RDBMS will be available when the user wants it. Initial development is being done with PostgreSQL with a possible early port to Sybase and, if it meets the requirements, MySQL.

The current minimum requirement is that the DB supports SQL. There will probably be other requirements in terms of support for transactions, nested SELECTs, and so on but these aren't nailed down yet. A "nice to have" is support for Embedded-SQL, since that simplifies porting the CDBI (Cavor DataBase Interface) layer, but its absence could be worked around.

Third party -- several available. PostgreSQL used for development

The interface libraries are a key part of Cavor architecture. They provide APIs for developers wishing to add custom functionality to Cavor or to reuse Cavor code in other applications; they provide the interface between Cavor program components lending to flexibility and robustness; and they (particularly CDBI) insulate the bulk of Cavor code from peculiarities of particular platforms or other components to ease portability. The principle interface components are:

A library package that provides a uniform C/C++ interface to the various database packages supported. It acts as a layer between the native database API and the rest of Cavor. It also provides an API to other applications that want to access Cavor objects (drawings, entities, etc.) without them needing to know the details of the database implementation.

Implementation started.

Provides a facility for controlling the graphics display (eg the map), drawing arbitrary graphics, opening different views, zooming, panning, selecting graphic elements, etc. Again there is a level of abstraction here: the graphics display is typically to X Windows, but other displays could be supported by the back end. (Indeed, PostScript is already partially supported.)

This gives applications access to the CSL (Cavor Scripting Language) Processor. This includes the capability to issue CSL commands as well as access and update the CSLP symbol table (ie, to get or set the value of CSL variables.) This also provides a way of extending CSL: a process can register itself via the CLSI to receive and process new commands from CSL scripts.

Partially implemented.

This is sort of the "master control program" for Cavor applications. It has several key subsystems:

Pieces exist, see below.

This subsystem reads script files (and commands it receives via CLSI), syntax checks them, and either routes them to an appropriate registered process to handle them (see Switchboard) or handles them itself.

The "memory" for the interpreter. CSL variables are stored here. Currently only handles simple variables (numbers and strings). At some point I want to add arrays/lists/structures etc.

Routes command messages from one Cavor process to another in a hub-and-spoke arrangement. Thus a command from a Tk pushbutton to zoom-out a graphics view is simply routed from the GUI-TK process to the CDL process.

A mini language processor in its own right. For handling complex graphic display issues based on an entities graphic path plus its attributes. For example, a telephone cable might be digitized as a simple polyline entity, but might display as a blue line with interspersed letter 'B' if it is a buried cable, or an interspersed special symbol for fiber optic, and also its actual length and or manufacturer's name might be displayed somewhere in the middle. Rather than require the user to digitize this exactly as it must be displayed, a short symbology language script is written which handles these details for all cable features, based on attributes in the database.

As another example, a PERT chart application will want to display the task boxes differently (line width, color, shape) depending on whether the task is completed, late, or on schedule, and whether it is on the critical path. Various task attributes (duration, resource, start date, etc) will also need to be placed according to user preferences, and easily changed. This can all be done with an appropriate symbology language script.

The various symbology language scripts are stored in a symbology library; different applications would have different symbology libraries. Library entries are related to entities via the entity code name (sometimes called feature code). (Exact implementation is TBD, it may make sense to store this stuff in the database, or as some sort of archive or zip file.)

A collection of pre-drawn graphical symbols that can be used in a graphics display. For example, rather than explicitly doing the "draw line" commands for a star, one could do the "use symbol 'star'" command (assuming that star was defined in the active symbol library). These can be of arbitrary complexity. (It should be possible to edit the various symbols using the graphics capabilities of Cavor itself. It should also be possible to import/export symbols from/to other vector graphic formats.) The limitations are basically that the symbol can contain multiple moves and draws, but any color or line thickness is ignored (overridden when the symbol is used). The symbol entry also contains baseline and size information for applying placement, rotation and scaling when used.

Update: The symbols will be stored in XML SVG (Scalable Vector Graphics) format, which is used by other programs (KIllustrator, Dia, Sodipodi). It may (TBD) be possible to interchange symbol libraries with Dia's "shape sheets".

Conceptually similar to the Symbol Library, used for rendering text strings. The CDL contains one default built-in font. Note: it probably makes more sense to write the code to use existing e.g. True Type font libraries rather than reinvent this particular wheel. Used to allow for different styles of text in the graphics display.

Not yet implemented.

This component allows for the building of graphical user interfaces -- forms, dialogs, menus, etc. -- to customize the Cavor user interface to particular applications. This includes some capability to automatically generate form (or form-like) interfaces to attribute tables in the database. Currently, to the extent this exists at all it is based on Tk (as in Tcl/Tk). Unless it turns out that there are some desired capabilities or features that we'd like for Cavor that Tk can't meet, the GUI TK will probably remain Tk-based rather than expend the effort to design and build yet another GUI toolkit. The basic requirements of the GUI-TK are that it allow for dynamic creation of GUI dialogs, etc from the scripting language; that it can issue commands (e.g. in response to a pushbutton) to the CSLP; and that supplemental C/C++ programs with a GUI can also be manipulated by and in turn manipulate the CSLP.

Partially implemented by extending Tcl/Tk.

You may copy, distribute or modify this document under the terms of the GPL only in conjunction with the associated Cavor software.