wftk core: datasheet repository adaptor

[ back to the core ] [ discussion ]

A datasheet repository adaptor is responsible for interfacing with a storage system in order to store datasheets. The datasheet, as far as the library is concerned, is an XML construct which contains the detailed state of a process, any values associated with it, and its enactment history. Where those components are actually stored are irrelevant for the library; finding them and putting them together are the business of the datasheet repository adaptor.

The simplest of all possible dsrep adaptors, of course (and the one which was used for the prototype, again of course) is one which stores all the datasheets as explicit XML files in a central directory. That's the DSREP_localxml adaptor. Other dsrep adaptors will store the datasheet in a BLOB column of the process table, borrowed from a task adaptor, or what have you. I'm sure each implementation of a workflow system will bring new ideas to light.

(January 27, 2002): The above text was written about two and a half years ago. The default "datasheet adaptor" is now the repository, of course, but the ability remains to interface with some system directly. To be honest, at this point I'm not sure whether there's any real-world motivation to do things this way. Consider it an exercise in archaeology.

These are the functions exposed by a datasheet repository adaptor:
0: init   Initialize adaptor instance
1: free   Clean up instance before shutting down
2: info   Return XML describing the adaptor
3: new Datasheet ID Create datasheet. Accepts NULL ID, in which case it generates a unique one.
4: load Datasheet ID Load datasheet into memory. Returns datasheet.
5: save Datasheet XML structure Save datasheet. Note that the ID might not be unique, because we might be storing or moving an existing one. In this case, we need to fail.
6: delete Datasheet ID Deletes datasheet from the repository.
7: archive Datasheet ID, archive name Archives a datasheet (removes it from the active repository and does something as yet unknown with it.)
Individual adaptor class handlers may implement additional functions, which will then presumably be available to scripting engines or something. (Who knows, at this rate, wftk will be primarily useful as a scripting language lingua franca.)


This code and documentation are released under the terms of the GNU license. They are additionally copyright (c) 2000, 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.