Repository manager: data management wftk-style

[ xml source ] [ discussion ]
The repository manager began its life as a redesign and port of code I'd been working on for a couple of years in Perl, called "OPM" -- Online Publication Manager. The point of OPM was to manage websites in a data-driven manner, pretty much what we all call "content management" nowadays, but it was difficult to work with and difficult to modify, and at some point it just ground to a halt due to sheer maintenance overhead.

Since I've pulled that groundwork into the wftk project, I hope for synergy on both ends: on the one hand, the adaptor architecture should make the repository manager easy to extend, and on the other, the repmgr also embodies and encapsulates a lot of the motivation for workflow in the first place, providing a nice framework for content management.

The executable itself is a command-line affair; once I have the time to mess with it, I'll extend it to include CGI execution, and of course once I get the server daemon framework running we can start to think about a repository manager service which would listen on specialty and FTP ports, maybe. Or something. I guess that will all be obvious once we get that far.

At any rate, unlike the popup framework, the repository manager is written in nice, safe ANSI C. Like most of the wftk, it is organized into two sections: the bulk of the work is in a library, and there is a command-line wrapper around that library. The library can thus be dropped into any application. The command-line wrapper assumes that the repository definition will be found in site.opm in the current directory (the .opm extension is, of course, a holdover from OPM and allows association under Windows for a GUI front-end, forthcoming if I ever finish it), but the library doesn't really care where you found your repository definition.

The repository manager can be thought of as

As such, it's squarely positioned to do a lot of the back-office tasks required by a medium-sized business organizational unit. Along with wftk for workflow and task management, plus some GUI framework to present the whole thing in a manageable way, we're on our way to a solid set of enterprise software.

A repository is essentially a directory which contains arbitrary objects and lists of objects. Objects have fields, sublists, and attachments; lists are loose organizations of objects which may or may not impose constraints on their structure. Lists may be stored in many different ways, so a repository has the capability of managing data in relational databases, local files, or anything in between, assuming that suitable adaptors have been written and configured.

Besides these datasources, a repository also manages data sinks. Data sinks may be HTML pages, they may be email addresses for notification of events, they may be remote connections -- whatever. And the final element of a repository definition is all the links between data sources and data sinks, which I call publishers from the original OPM code. A publisher is invoked when a datasource registers a change, and updates whatever target data it is responsible for (or sends an email, or starts a workflow process, or whatever.)

A publisher uses a tool to effect these data changes; tool definition is still a pretty vague area, so at this point, it's hardwired. Basically, there are two tools at the moment: template application, which takes structured data and weaves HTML-like text from it, and a Wiki tool, which takes text with a simple-to-edit markup and weaves fairly well-formatted HTML from that. My Wiki tool is very repository-aware, even to the point where it is able to maintain a todo list for problems it encounters during formatting, use a "link" data source to manage external links, and so on.

Links to the pieces:
This code and documentation are released under the terms of the GNU license. They are copyright (c) 2001-2005, Vivtek. All rights reserved except those explicitly granted under the terms of the GNU license. This presentation was prepared with LPML. Try literate programming. You'll like it.