Metakit is a C++ database library, and is used as the persistence engine underneath WiKit. If it works as intended, you'll never have to deal with any of it, because one of its goals is to help you stay out of trouble.
It was developed, and is actively supported, by jcw.
As of 2012-11-30, the most recent release, 220.127.116.11, does not build against Tcl-8.6. Use the latest repository code instead.
For what it's worth, here are the points I found most useful in the Roseman intro:
http://www.equi4.com/metakit/wiki.cgi/ was an official wiki for Metakit
"... many of the integrity checks required in traditional database use are not required in Metakit, because Metakit offers nested views -- a cleaner way to represent the relationships often enforced by integrity constraints."
"cleaner" is a matter of opinion, ask a relational database theorist. I don't want to start those arguments here, just point out that if you use Metakit for a complex system, you should design first, and be very careful. - EMJ
DKF: "You should design first"? That's actually true of any non-trivial program, you know... ;^) An ounce of thought saves a ton of effort.
AMG: Even though Metakit serves as one possible foundation for Tclkit VFS storage, Metakit itself is not implemented in terms of Tcl or the Tcl VFS. Therefore Metakit cannot open a database which is stored inside a Tcl VFS. Consequently, it is not possible to access or create a Starkit located inside of a VFS, and Starkits must be created as normal operating system-visible files.
This is disappointing. I discovered this shortcoming while developing a Starpack that itself creates various Starpacks assembled from bits and pieces of itself, and I wanted it to not have to make temporary files. Temporary files are a real pain on Windows due to leaked file descriptors preventing my application from deleting them until after the application exits, which is really tricky. Creating everything in memory and writing out only the final product would be ideal.
After enough finagling, I was able to meet my goal. Even though the database itself (i.e. the Starpack) must not be in a VFS, the files to copy into it absolutely can be. All I have to do is put the Starpack out where the OS and Metakit can see it, and I'm good to go. Since I eventually was going to copy that file from a VFS to disk, this is just fine.
Update: not quite. Icon replacement doesn't work. Even though I'm able to keep the temporary copy of the runtime in a VFS to avoid cluttering the disk and have it be used for the runtime stub when wrapping, the icon replacement code tries to mount it to find the original icon file. This fails because, like I said, Metakit bypasses Tcl and goes straight to the OS to try and open its database file. Short of hacking up SDX, I guess I'm stuck making the temporary file be on disk. That wouldn't be so bad if Metakit didn't seem to leak the file descriptor.
Update 2: The leaked file descriptors were due to me calling [vfs::filesystem unmount] rather than [vfs::unmount]. The former bypasses the registered unmount handler, so Metakit is never asked to close its file.
alexshpilkin: Metakit now has a extension for the Jim interpreter, too (not yet released as of Sep 3 2011, but available in Git) -- couldn't get in touch with jcw, so no search support for now. The documentation is at http://jim.berlios.de/documentation/metakit
jcw 2005-11-09: There were two pages called "Metakit" in this wiki, due to some old renaming glitches. I've manually adjusted things to resolve this (the "lost" copy was on page 478). Below is the original text.''
Hof: Metakit is included in lib/mk4tcl as of tcl 8.4.4, but without documentation, it seems.
RLH 2017-08-02: I wonder what it would take to get this back out there? I always liked playing around with it.