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

Workspaces

(Anyone else remember APL?)

Your tcl/Python/Java/Scheme/PERL program can store over a gigabyte of data `natively', live, in variables, arrays, dictionaries.

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 the opposite.

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