Re: RFC 287 (v1) Improve Perl Persistance
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
Re: RFC 287 (v1) Improve Perl Persistance
On Mon, Sep 25, 2000 at 09:40:52AM -0400, Michael Maraist wrote: 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. :) On the one hand, there's TMTOWTDI. On the other hand, there's overly complicating things with a maze of twisty, turny modules, mostly alike. I'm not arguing against TMTOWTDI. I'm arguing that what we have isn't making easy things easy, but actually inadvertantly making easy things harder than they should be. 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. No complaints. Why do they need to be provided by mutually exclusive sets of modules? 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). Actually, I don't. The *DBM_File modules work, as do Data::Dumper and its kin. This RFC is a request to improve the interoperability of those modules, not implement any of them from scratch. Z.
RFC 287 (v1) Improve Perl Persistance
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Improve Perl Persistance =head1 VERSION Maintainer: Adam Turoff [EMAIL PROTECTED] Date: 24 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 287 Version: 1 Status: Developing =head1 ABSTRACT Many mechanisms exist to make perl code and data persistant. They should be cleaned up, unified, and documented widely within the core documentation. =head1 DESCRIPTION Tom Christiansen proposed this in his perl6storm message: =item perl6storm #0022 make marshalling easy. core module? would this allow for easy persistence of data structures other than dbm files? general persistence is hard, right? can this be an attribute? Python offers one way to make code/data persistant: the Cpickle interface. More complex serialization can be accomplished through the 'shelve' interface or DBM files. This capability is quite useful, widely known and easily used. Perl, by comparison, offers Data::Dumper, which can serialize Perl objects that are rather asymetrically reconstituted by using Ceval or Cdo. Perl also offers solid, simple interfaces into DBM and Berkeley DB files, and offer a well known, low-level serialization mechanism. CPAN offers many other serialization modules that are only slightly different than Data::Dumper. This plethora of serialization mechanisms confuses users and adds to code bloat when multiple modules each use different serialization mechanisms that are all substantially similar. Something similar to Python's Cpickle interface should be added into Perl as a builtin; this feature should have a symmetric "restore" builtin (eg save()/restore(), freeze()/thaw(), dump()/undump()...). Furthermore, Perl's low level serialization machinery (DBM, SDBM, GDBM, Berkeley DB) should be unified into a single core module, where the underlying DBM implementations are pluggable drivers, like DBI's DBD infrastructure. =head1 IMPLEMENTATION First, the issue of adding builtin serialization functions needs to be addressed. This is a language issue because serialization should be more visible than it is today, and the best way to accomplish that is to include this feature as a pair of builtin functions. If this feature is implemented through a core module, that module might best be presented as a pragmatic module. Finally, although this proposal describes a simple matter of programming, some of the issues (such as pluggable interfaces) are best hashed out at a language-design level, so that they may be used elsewhere, easily. =head1 REFERENCES Python Pocket Reference, Chapter 12 perl6storm
