wftk -- Initial implementation

Topic: wftk -- Initial implementation

The implementation of wftk (or better, as I've titled it, the "initial implementation") has been split into two parts: the core engine and other "doing workflow" kinds of things, and then the workflow process definition editor. I stress the "initial implementation" because the whole point of this effort is to modularize things to the point where any component will surely be replaced entirely many times, especially for use in differing environments.

I've begun the first part, and that breaks down into the following components:

The active process repository and to-do list management.
I was rather surprised by this, but to-do list management is really very central to what this whole thing is all about. If I have a to-do manager, then essentially adding workflow consists of two hooks: first, the workflow engine can create new tasks for me, and second, when I complete a task, the workflow engine decides what to do about it. The to-do manager is growing out of some other work that I've been mulling over for a while, and its initial implementation is here. This implementation is AOLserver/Tcl (the same platform running the site you're reading right now), partly due to my need to get it up quickly, and partly to underscore the point that any implementation of the user interface should work just the same with the rest of the system.
The core engine
The core engine itself is that part of the system which is called to create new processes, and to complete tasks. In each case, the engine decides what to activate next. That's essentially all it needs to do (yes, it is slightly more complicated than that.)
The datasheet repository and process definition repository
Due to (premature) mulling over of what it will take to create a Web-based editor for the XML process definition, I've come up with a dandy little component for both repositories. Each of these repositories is used to store XML documents, so I'm working out a protocol by which pieces of those documents may be retrieved, not just the entire document at one fell swoop. This component will use intra-document locations to retrieve and modify single elements and values.

April 20, 2000

At this point, the first round of development is complete for the task list manager, even though I still really haven't decided whether it's a task list manager or a to-do list manager. It's running here. You can use the userid 'demo' and password 'demo', or you can ask me for a different userid for yourself if you want to really bang on it. I'd appreciate any suggestions or comments short of derisive laughter. It's raw but I think it's usable. Your mileage may, of course, vary; if so, please drop me a line.

For my next trick I'll be attacking the datasheet repository. This will allow me to attach arbitrary values to tasks (and of course to anything else I like, heh, heh). It will be an XML-based solution, and like the task list manager, I will be developing it to be useful as an independent application. The same component will also be used to develop the process definition repository and editor. More on that theme in a day or two.

Once the datasheet repository is working, then I can do the core engine itself; the reason I'm not doing that first is that the engine will store process and task state information in the datasheet. I guess I could do that in the database, but at the moment it seems to make more sense this way. Anyway, that's my plan. Watch this space for further details.

All in all, this project is getting bigger as I get closer. (Of course, I expected that but it's always so surprising.) I think this task list manager is a good, solid start.

May 13, 2000

Datasheet attachment is working, and you can scope out the code here, mostly. I wrote the whole thing based on my command-line XML utilities, which are in turn based on James Clark's expat parser. Anyway, finally knowing how the heck to use expat means I'm close to finishing this longest of all project milestones.

May 27, 2000

Well, that was a grueling two weeks. The bare bones of a core engine are now working. You can see things here. The basic implementation of the core engine is as a rather simple command-line program which is given a command such as "start this process with this process definition", loads the definition, creates a datasheet, then replies with a list of the tasks to be started. When a task completes, the commend is given "complete this task in this process", and the engine gets the datasheet (which contains the current dependency state of the process among other things), retrieves the process definition again, and tells you what happens next.

Integration of that with the task manager required yet another piece to be started, and that's the process definition manager (or PDM). The PDM knows how to find the current version of a process definition (or procdef), how to present the list of procdefs, how to generate an initial startup form for a process from its definition, and so forth. The PDM will also manage editing in the next milestone. You can see the PDM's code here.

July 10, 2000

OK. The procdef manager, or PDM, is now a working prototype. You can run it here and browse the code here. The implementation of the PDM is in C and it runs either from the command line (for many functions) or as a CGI program. It auto-detects which mode you're running it in. Cool, eh? Anyway, I developed a user module during this phase of development which provides a very fine-grained control over users and the actions they're permitted to take. That functionality now has to go into the rest of the system (primarily the task manager, but wftk core will also need to use it in some cases.)

Man, there's still a lot to do here.