Perl tutorial: Now that I have a small subset of the data services
written in Perl, I've started writing unit tests -- for the simple reason that
I can't remember what I've already done, and I worry about breaking it. From
the unit tests, I'm writing example code (or rather, the other way around),
and I'm organizing the example code into a tutorial. This is
kind of exciting, actually.
The Muse suddenly decided that what I really needed to do this year
is rebuild the wftk from the ground up in Perl. Who am I to argue? I'm
following the hierarchy of services outlined in my blog post, so I'm building the data manipulation services first.
I've started Wiki-izing this descriptive material and hope to get serious with wftk2.0 sometime this year.
Here is my blog post last year
about how I see my refactoring project working.
GUI work: Actual development! I have been toying with small, easy-to-implement applications over at
Anappaweek.com and have gotten the wxpywf framework working at a minimum
level of functionality. This framework interfaces the wftk with wxPython, and it's got a long way to go before it's
a general-purpose workflow interface, but man this is a powerful first step. A good omen for 2007!
General hello: I've had a stressful couple of years, but wftk has ever so slowly progressed during that time.
My current focus is to get a series of tutorial systems working.
Java and SOAP:
The German trip was very fruitful; not only do I have an initial Java client
working, I also have a SOAP server for it to work against. So while you still
can't base a wftk server on Java (e.g. Tomcat), you can run wftk as a
Web service and write Java code against it. I will have downloadable installation
materials as soon as humanly possible.
Also in August, I managed to lose all my stored email for the last few months. If you emailed me this summer, do so again -- especially if you're Hungarian or interested in Java (you both know who you are).
Real development again:
June and July were very busy months, and August even more so:
in June, I developed (for pay) a wxPython GUI demo program which
I will soon be cleaning up and making available for download. I also
have an initial SOAP adaptor which allows arbitrary Web service
interfacing from a running workflow process. (The Python wrapper allows
the exposure of wftk functionality as a Web service, but I don't have an
example working yet.) I completed the long-awaited repmgr/wftk core
integration which has been holding me up for so long. And finally,
I am off to Germany tomorrow for a real live consulting trip, in
the course of which an initial JNI wrapper will be written, as
the first step in the wftk-j plan.
Note: none of the stuff I mention above is available for download yet, since I've been far too busy actually getting it all to work in the first place, but hopefully I'll have time in Germany to roll it all up into a new release. If not, it'll be shortly after that -- in September for sure. If you're really, really chomping at the bit, email me. I respond well to attention.
I really thought a Zope interface would come more quickly than the JNI wrapper. Go figure.
|Examples and docs: I had a bunch of example work I had forgotten to upload. So have fun with it. No, I'm not dead yet, concerned emails notwithstanding. 2002 was, however, a financially challenging year for me. If you've thought of hiring me for some consulting or development work, well, now's your chance.
|WebDAV: How does a WebDAV adaptor strike you? I think it sounds so amazingly cool I'm wondering what rock I've been hiding under.
|New adaptor: It's a simple thing, but the LIST_delim adaptor is new: it stores records as tab-delimited lines in a file. I've made it part of the standard repmgr complement.
|Clients: Started work in the last week on two clients of actual significance; both use the repmgr API, not the wftk API: the first is a CGI interface to the repmgr, and the second is a mail handler for incoming mail. The two of these will make a real live system possible -- although given the current absence of integration between repmgr and wftk core modules, it's still not a workflow system. But I'm getting ever closer.
|v1.0: OK, it's released. You can download from Sourceforge, or you can wait for me to get it onto the server hereabouts. I've (gulp) submitted the project to Freshmeat. I fully expect a whole bunch of people kibitzing about lack of testing, lack of documentation, and so forth. Sigh. The story of my life. And yet I keep soldiering on. Download notes: The tgz I tossed to SourceForge was corrupted; if you're one of the 27 people who downloaded it, sorry. It's fixed now, or you can get it from the download page here. Yes, although it's confusing, the current download for v1.0 is wftk-1.0pre2. As you may be able to see from my timeline, I get nervous when I move too quickly.
|wftk core v1.0pre2: I just now finished up coding for the version-1.0 release of the core engine. This new code (now committed to CVS) contains all you need for state-based workflow, which is what I thought was still lacking. There are, of course, no shortage of TODO points even in the existing code, but hey -- this is starting to look like a workflow engine or something. This code needs testing. I am a lousy tester. Thus, as soon as I wrap it up and put together enough docs that a rocket scientist could use it (you know who you are) I'd greatly appreciate any bug submissions.
I've been writing documentation. Yeah, it's true! And I've also put
said documentation into CVS at SourceForge, meaning there's some
vain hope that it'll stay up to date. Wow. See in particular
my plans and the the
new code overview.
Native Java: I've officially declared this summer solstice to be the announcement day of wftk-j, the port of wftk into native Java. If you're interested, and especially if you can contribute funding for any part of this effort, tell me.
|OK, here's the situation. I really want to close off a version 1.0 for the core workflow engine so that I can have some sense of closure before going on to integrate the repository manager with the workflow engine. And I really wanted to get that done in May, and so I defined the cutoff point in my mind to be that point where I can define a datasheet DTD and not have to change it greatly in the coming months. And I got to that point! But then I realized that I really want to add a state-based workflow paradigm to the core engine before I call it version 1.0, and so that's what I'm doing now. Just another solid day or two worth of work and I'll release it. Everything but state-based workflow is available on CVS. Once I have things working with state-based workflow, I'll wrap up a tarball, submit the whole thing to Freshmeat, and see what happens. And immediately continue work on version 1.1 or 1.5 or whatever.
|Rumors of my death have been greatly exaggerated. But what have I been doing, you ask? I've been quite busy addressing the lingering concerns I have had about organization of datasheets, resulting in a whole new system I call the repository manager -- details will be forthcoming soon and I'll link to them here; please see the new overview document for a little more info. Also, I've started work on some real-life examples of applying the wftk. These examples will hopefully generate some useful scaled-down sample code, and I'm also working on documentation in general, at long last. Thanks to everyone who's expressed interest in my little obsession.
|The latest version is now 0.9.5 beta. This contains lotsa new stuff: Oracle integration, the ability to store datasheets in the database, transparent writethrough of values from the datasheet into the database, and lots more stability. Even a little more documentation, although not enough. But it's getting there.
|Whew. The CVS source is now good. Compilation problems on Solaris have been fixed up and are available via CVS -- and that version still compiles on Windows. CVS is a Good Thing. Wouldn't it be neat to be able to approve commit batches with an arbitrary workflow process?
The wftk now works well with Oracle, the first of several database adaptors I hope to write in the near future. I've got
CVS working at the Sourceforge project page, and my current code is in
there. Please be warned: my current code is a holy terror of a mess. There are obsolete files all over the place. So take
it all with a grain of salt.
For Windows users, I've worked out dynamic loading of adaptors (I'm already familiar with how DLLs work -- getting dynaloading working on Unix will take some work). This means that seldom-used adaptors (say, the ODBC adaptor if you're running Oracle) don't clutter things up. This will move to Unix as well as soon as I screw my courage up to implement it.
On the horizon: Integration with Zope and with ColdFusion. Database adaptors for PostgreSQL, MySQL, and Sybase. Perl integration ("use Workflow;") and a CPAN module. Python integration (that's part of the Zope integration, of course.)
|Finally started getting the documentation whipped into shape. And it's official: wftk has its first paying project. The Staatsarchiv Nordrhein-Westfalen needs workflow (and a whole lot of other stuff, but workflow's part of the project.) And it's going to be wftk.
|Set up a SourceForge project today. Now I just have to figure out how to use all that stuff. The mailing list should be online very soon, and as soon as possible I'll get things into CVS.
|Got things compiling under Solaris today and there's a new download distro which has properly functional makefiles and all that, plus it's named in such a way that your package managers won't freak.
The wftk (open-source workflow toolkit) is a workflow engine in library form which can be integrated with whatever you need to integrate with. It's designed on a very flexible adaptor architecture, whereby interfaces to external functionality are defined and implemented as independently as possible of the core workflow logic. It makes heavy use of XML, so that its data structures are always easily inspected. All it lacks (soon to be rectified) is experience in Real Life.
The documentation is still being written, but you can see what I've done so far -- and I'd appreciate any feedback or comments you may have.
Of particular interest are the following headings:
- An overview of the wftk system.
- A backgrounder on workflow and wftk (sort of a white paper, recently revised.)
- Examples of wftk applications
- The source code in literate-programming form
- The start of the API programming documentation -- incomplete.
This version of the project home page is really just to show that I'm alive and that the beta is available. This is what I still have to do in the very near future:
- Get the "real" domains installed and ready: wftk.com and wftk.org. They're bought and paid for.
- Write CGI interfaces to everything. This won't be too hard. At the moment, however, there is no HTML interface to the current version, and that's just not particularly acceptible.
- Set up a new demo system based on the new code.
- Rewrite the procdef manager code to be library-based. Additionally that will be used to present and work with ad-hoc workflow.
- Document what the heck I've done here. The docs are thin, people, real thin.
- Integrate with Zope.
- Integrate with PostgreSQL and MySQL (both actual requests).
- Get a few implementation projects under my belt so I can call this a v1.0 production release.
I'd like to talk to you about that last point. Presumably you're interested in implementing a workflow system of some kind, otherwise you wouldn't be here. Give me a shot. I can do a limited number of free-of-charge consultations or even implementations; I'd be happy, given telnet/ssh access, to do some debugging in your environment, and of course if you want to hire me, I'm very attentive. I've got a couple of leads on implementation projects already and I'd really like to add yours to the list. I really want to see wftk work right, and concrete project implementations are the only way to make that work.
Mail me if you're interested. My schedule is, um, regularity-challenged, to say the least, so if you want to do the voice thing, set up a time to call, if you would.
Besides just "plain workflow" I'm extremely interested in integrating wftk as an internal module in other systems. The Zope community has expressed a need for workflow functionality, and I'll be working on that in the near future. Another possibility which has occurred to me is that it'd be nice to use wftk as an organized means of approval for changes in database information. I can easily see wftk being set up as a set of PostgreSQL triggers -- thus any UPDATE command would be converted into a request for a change, which wftk would manage until approval was granted and the change actually made. Workflow is a very powerful idea, and I think that the absence of any open-source workflow engine (until now!) has precluded serious thought as to how powerful it can be.
Anyway, that's a taste. I'm also looking at what it'll take to port the engine into a parallel Java/EJB implementation. Film at 11.