Blue Sky

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.

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
MOOs
MUSHes
M*
Good way to store those objects.

ColdStore could almost have been designed to implement a M* :)

Document Stores