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.)|
|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.|