I am not certain how big Sleepycat's release is any more, but I think a DB::Inline done with Inline.pm wrapping sleepycat code would be an interesting project. That might just move the problem from library synchronization to making sure that everyone has access to a compiler though.
I would like to hear more about the "record level locking and transactions." Perltie does not support these features: what will the interface look like? My own efforts to do record level locking with DirDB from above the perltie are done by: reserve a record key for held lock id (such as "LOCKEDBY") create a thread-unique identifier ("TUI") WAIT: wait until LOCKEDBY is undefined or set to a reserved "NOONE" value (and not stale -- staleness is a severe problem) write the TUI to the held lock field wait as long as it might take a different thread to write its TUI (implementation-dependent) read the held lock field, if it does not match what I just wrote there return to WAIT now I have exclusive access to the record so I can increment or decrement the transaction-safe field set the held lock field back to NOONE (or delete it) but some of the details could very well be done with additional methods, such as tied(%Record) -> Set_Exclusive_Lock(); $Record{BALANCE} += $fee; tied(%Record) -> Clear_Lock(); Are there other TIEHASH modules that implement such things, and what names do they use? When you are the first to add a feature like this, I think it is a good idea to try to name the methods by function so that other implementations of the same semantic can reuse your interface. If you're making up your own file format, how about CorlissDB? You said "support tied hashes" -- Did you mean support for storing hash references? I added support for hash references to my DirDB (and DirDB::FTP) modules and would appreciate your feedback on the semantics of the interface. They are as follows: When you store a reference to a native perl hash to DirDB, the hash becomes blessed so that further manipulation of the referenced hash manipulates the persistent store as well. When you store a reference to a tied hash to DirDB, you get a deep copy. When you store anything other than a scalar or an unblessed hash reference, the module throws a croak without overwriting or corrupting These semantics make it possible to do multi-level autovivification inside a DirDB data structure, even over the network (by FTP.) On Fri, 2004-01-02 at 12:48, Arthur Corliss wrote: > [...] Modules like > AnyDBM_File and DB_File are causing some unpredictable results in some of my > code, depending on the version and implementation of the dbm libs they're > linked against. This is just my way of getting predictable results without > requiring admins to upgrade or install new system libs, along with the > requisite Perl modules. > > --Arthur Corliss > Bolverk's Lair -- http://arthur.corlissfamily.org/ > Digital Mages -- http://www.digitalmages.com/ > "Live Free or Die, the Only Way to Live" -- NH State Motto -- david nicol And now for something boldly anticlimactic.