> Many mechanisms exist to make perl code and data persistant. They should
> be cleaned up, unified, and documented widely within the core
> documentation.
>
But doesn't this go against TMTOWTDI. :)
Different people might have different requirements. Portability would want
all ASCII, large apps might want compacted (if not compressed) storage,
while others might want highly-efficient storage. Ideally it's a perl
module, but for efficiency, it has to be a c-module. And that's just for
the pickle. Shelving has a multitude of possibilities; most of which rely
on OS installed libraries.
Essentially, what would have to happen would be that perl has a built in DB
package (or at least include the C-source for it's own implementation).
This might not be a small feat. I'm not sure which DB package Python uses.
Just about every language now has a form of serialization (with versioning).
If any of the above would be accomplished, this would be it. Pick one of
the many 'freeze/thaw'-type modules, then apply a linear and versions
serialization routine. You might want to extend this RFC to include
information about existing serialization techniques (which tend to be more
sophisticated than raw dumping of a data-structure). Essentially in an OO
design, each class needs a way of appending it's persistent data to the
stream; this would have to avoid anything like a file-handle, or cached/tmp
information. It's non trivial to do currently (to my knowledge).
-Michael
