It is implemented (mostly) in ANSI C. The source code is actually contained in XML files which are sliced and diced by a Perl script to produce the C code which is compiled. The reason for doing this is because the same files contain implementation documentation. This technique is called literate programming, and it works for me. Your mileage may vary.
The HTML documentation generated during the compilation ends up in the source directories; to make things easy for a documentation distribution, however, all these files are duplicated in the code subdirectory here.
This document is an overview and index; jump to various pieces of it as follows. The list of interfacing systems is largely vaporware at present, but it gives you an idea of what goes where.
After core-v1.0 is released, I'll be polishing up the other central module, the repository manager, as a sorta-kinda separate product. Weirdly, the repmgr is the module I'm using more heavily in production. The repmgr handles data, and I handle a lot of data, so I guess that makes sense. The repmgr will be released as repmgr-v1.0. Once that's done, I'll integrate the two modules and release the whole thing as wftk-v1.5. It will continue to be possible to run the wftk core engine without the repository manager; this may be useful for embedded systems, etc.
The relationship between the two central modules, adaptors, and application or wrapper code is explained and depicted in the wftk overview.
Both central modules rely on some shared code: the XMLAPI (described below) and the context handling functionality, which also includes handling of adaptors and configuration information. Read the code for more information.
Central modules, supporting code and command-line utilities:
The XMLAPI uses the expat parser for all parsing (whether from file or from string.)
There are three XMLAPI extension modules: xmlobj uses the XMLAPI to do record management for the repmgr and datasheet management for the wftk core; xml_template does a kind of simple XSLT for the repmgr; and xmlcgi takes the current CGI environment and builds an XML lookup structure for easy C/CGI programming.
XML handling functionality:
There are thus two types of wrapper, the UI wrapper (a complete program, a category with no members currently complete) and the scripting wrapper (an interface for a scripting language, currently represented by Python and Tcl.) Note that there is a lot of hope inherent in this list.
UI wrappers:
The wftk core engine uses most of the adaptor classes in this list; the repository manager makes due mostly with the "list" class, which represents generalized table-like entities with records in them. Click on each class to get an overview (many of these are out of date, so I apologize in advance) or on any implemented adaptor to see its code.
Read this overview of how local adaptors are managed.
The following classes of adaptors are defined (so far):
ACTION: invoking external APIs (wftk core)