Introduction to the Conglomerate architecture


The original codebase used "raw" GTK+, but now the code requires Gnome so that it can take advantage of Gnome's Virtual File System and the Bonobo component technology.  It uses a custom widget based on    GtkDrawingArea as the core widget in the editor frontend.  An attempt was made to rewrite the core widget using GnomeCanvas (the congle tree in CVS), but this code has been abandoned for now.

Conglomerate originally built heavily on the Flux library, a toolkit library of highly reusable code which we developed as a fundament for this and other projects we work on, like FIDEL. However Conglomerate development languished for two years whilst Flux development continued, and the two projects gradually became incompatible. So we've been working towards removing the Flux dependency, using standard GNOME libraries instead. In particular, the XML parsing and internal representation is being ported from Flux to libxml2, by using CongNodePtr as an alias to the actual type being used.

We hope to have removed the Flux dependency by the end of 2002. You should be able to find an introduction to working with Flux here. However this may be misleading due to the drift between the projects.

The editor is designed to be able to handle any valid XML1.0 DTD. It loads the DTD from the server, and then loads a "displayspec", a small file which adds display meta-information to the DTD. For instance, the displayspec defines which elements in the DTD should be block elements, and which should be span elements, as well as the colors of the elements, and the names (so that complex in-DTD names can be mapped to simpler ones in the editor, the display can be in a different language without having to change the DTD, etc.) See the screenshots if you're uncertain of the difference between block elements and span elements, or on how color is used in the editor. The displayspec means that the work required to start editing any given DTD with the Conglomerate editor is limited to a few minutes per element, unless someone already made the displayspec for the DTD. In the future, the editor will have a GUI displayspec editor, which lets you see your changes as you apply them, and lets you override the server's standard displayspec with your own preferences.

Originally, our plan was to implement an interface for binary plugins, which could register themselves as display and editing components for subtrees that the main editor couldn't adequatley display and/or edit (tables, like in the CALS table model, is an excellent example, and now, with XML namespaces, so would graphics in SVG format be). However, now that we're moving to Gnome, Bonobo seems like a much more sane choice; some preliminary tests of this have been implemented.

In the original codebase,the server stored, parsed, validated and   transformed XML, and   passed it to and from the client in the form of markup trees (see the   Flux documentation for more info). This has been abandoned for now; the current idea is to load and save XML files from a client-side virtual file system (currently GnomeVFS).  This allows us to work with various server implementations (e.g. FTP) and will let us add other types of server implementation in the future.  It also makes much more sense for users working solely on local documents.

The transformation and storage are the areas that are least developed at the moment. For transformation, the server uses a simple language we developed for the purpose, but we've been running into limitations as we deploy the system for our customers, so this is ripe for either a complete rewrite, or replacement with either a stylesheet language (like XSL) or an embedded scripting language with extensions to directly manipulate the markup tree (our choice would be Python).

There's more to come in this document, as the unfinished parts of Conglomerate get finalized, and we find the time to describe them. If you need/want to know more, this is for you:

Feel free to contact us, and/or join the mailing lists.