5. Tool architecture

5.1. Overview:

Graph-includes was initially developped with only a handful of ideas, and then started to grow as I noticed where useful things were missing. That initial phase was useful for me to get a grasp on the domain of dependency graphing, and provided the ground for a (hopefully) decent design, which still has to be completely implemented.

Together with blocking issues marked + in the TODO list, the implementation of this design shall be the goal for a 1.0 release.

The planned design is architectured as successive layers, all of which should be pluggable to allow a high degree of customization.

   source locator
         |
         v
  language selector
         |
         v
dependency extractor
         |
         v
graph transformations
         |
         v
      styling
         |
         v
   layout engine
         |
         v
     rendering

We will then be able to consider DEPS as being made of a number of parts:

This will hopefully make it easy for anyone to plug their own work at any place in the architecture.

5.2. State of things

Currently, transformations, styling and the renderer are properly customizable. A couple of transformations and styles are already available. The extractors are customizable as well, but the currently implemented mechanism is far from being generic enough.

Language selectors are intermixed with extractors. The current source locator is a local-tree one (alternatives would include SCM-aware locators), is hardcoded in the graph-includes script, and takes parameters from per-language extractors to find files.

There is no distinction (yet ?) between the layout engine and the renderer. In fact, it may not be easy to do this, since most layout engines are tied to a particular renderer.