This page last updated: Apr 24, 2006

About Hubs

The hubs are the heart of the uber-converter concept.  They provide a place for individual connectors (nodes) to terminate.  While existing file formats could have been made to work as hubs, it has thus-far proven more workable to design the hubs as simple YAML representations of the sanest possible data-structures.

Rhizopod

The first step in this evolution is rhizopod.  This represents the paradigm of 2D/3D CAD programs, without extensive linking and references.

Chromista

A divergence from Rhizopod, the Chromista hub is being designed to deal with 2D-only "designer graphics" such as SVG, XAR, PS, and PDF.

Design Notes

THIS PAGE IS IN FLUX The following will be moved shortly.

 flat
 |-- 1.yml
 |-- 19.yml
 |-- 2.yml
 |-- 3.yml
 `-- 4.yml

 nested
 `-- objects
     |-- meshes
     |   `-- spheres
     |       `-- 19.yml
     `-- planar
         |-- circles
         |   `-- 1.yml
         `-- lines
             `-- 2.yml

 rhizopod
 |-- 0.yml
 |-- 1.yml
 |-- 2.yml
 |-- 3.yml
 |-- DIRTYPE
 |-- drawing
 |-- layers
 |   `-- 0.yml
 |-- nextid
 `-- styles
     `-- 0.yml

Current consensus is that a flat directory will work better from the programming standpoint and would be easily transformed into other 'views' of the database.  In discussions about how to handle file headers and other non-geometric data, the structure seems to lead toward some division, but still avoids nesting.

Starting from a dwg file with a decent sampling of entities with various properties, we can create some example files (some preliminary examples.)  Note that these files do not necessarily reflect the specification in any particular way.

hub-node illustration
combinations graph

Formalization of concepts begins with the The "Hub Is a Node" Document.

References

• The cad-linux-dev mailing list archives.