The near future of ColdStore holds:
- Fine-grained Multithreading under pthreads/LinuxThreads.
- Deferred balanced BTree memory allocation or concurrent SkipList allocation (at the moment it uses a BFL.)
- Objects designed to support generic virtual machines.
- Objects designed to support structured text (SGML,XML trees/graphs).
- Network objects - handling tcp/ip connections of various kinds.
- STL port - persistent STL objects.
- At least one serious language: C--, a Self-like language
- More languages: Python, Tcl, possibly even Java.
- Richard Stallman is interested in a Guile port to ColdStore. Here are some notes, contact us if you would like to help.
Here's a more detailed list of things to do
- Virtual Reality
- Improve the performance of VRML systems by storing VRML
objects without having to parse them: you can render and operate
on them directly out of memory without reparsing. (And store your
Quake Levels the same way.)
- (Anyone else remember APL?)
Your tcl/Python/Java/Scheme/PERL program can store over a
gigabyte of data `natively', live, in variables, arrays,
In future versions of interpreters, programs/scripts
would never terminate, but merely freeze, their current
state captured in the coldstore. Thawing such an
interpreter would bring it back to the precise state it
was in, at the time of its freezing. EPCKPT
supports this right now, but tacitly assumes that
implementations will outlive objects (if .so files
change, the results are undefined.) ColdStore assumes
You don't need a database interface when everything's already got a name, or stored in something that does. The name we give to an object in a programming language is a unique key, which translates to the data contained within it ... this is just like a database index returning a record, but there's no need for a `select', it's already there.
- You Don't Need Files
- (well, except for backup.)
- Editors that never die.
- Editors that work directly on the parse-trees of the languages you're composing code for.
- Parsers that take input from those editors, feed back to them, and feed forward via directly stored Abstract Syntax Trees, to compilers generating code on the fly.
- MUDs, MOOsm MUSHes, M*
- It's a good way to store those objects. [ColdStore could
almost have been designed to implement a M* :) ]
- Document Stores
- Where the fun begins...
We think that ColdStore has potential. Here's what's in the
offing: from the nearly feasible to the bright blue sky. You can
probably help us out here.
Why ColdStore? An explanation of what we're up to.
The nitty-gritty: an explanation of ColdStore's design, what it
does, and what it might be used for.
Get it, compile it, run it, tweak it. Lather, rinse,
repeat: all with the fresh smell of GNU.
Though it sometimes feels that way, we're not the only ones thinking
about these things. A few references to articles on object persistence
and all that gubbins.
Praise the visionaries behind this thing; alternatively,
berate the guilty parties.
That Oscar acceptance speech in full.