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.
These are the functions exposed by a datasheet repository adaptor:
Function | Parameters | Purpose |
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.) |
Implementations:
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. |