Bug#127063: ITP: mird1 - Mird database library

[Krzysztof Krzyzaniak <eloy@transilvania.eu.org>]

Package: wnpp
Severity: wishlist


Package: mird-dev
Description: Mird database library (developer files)
  
Package: mird1
Description: Mird database library (runtime files)

URL: http://www.mirar.org/mird/
Licence: 
   The Mird database library may be freely distributed and used with these 
   limits:
      * The database library may be distributed with or without source.
      * There is no promise that this software works. (But if you find any
        bugs, please let me know!)
      * You can use this software for whatever you want. You don't have to
        pay me.
      * You may not pretend that you wrote this software. If you use it in
        a program, you must acknowledge it somewhere in your documentation.
	      
>From tutorial.txt:

   Mird is a database library, for operating on simple disk-based
   databases with the following features:
     * The database is key-value oriented, primarily - this is useful for
       most database operations, from inserting and removing lines in
       tables, and for object-oriented data, provided it's fast enough.
       (It should be.) The key can be either a 32-bit integer or a byte
       string of any size. (A integer-key table using 32 bit hash keys is
       used to store the string-key entries.)
     * The database consists of several tables or key-value mappings.
       On this level, the table is identified by a 32-bit integer. It is
       easy enough to implement a table name lookup table, when the need
       arises.
     * Changes to the database is made in the shell of transactions,
       where each transaction encapsulates any change to the database
       atomically.
     * More then one transaction could be in progress at any given
       moment, with resulting conflicts at the closing of the last
       transactions, if they operate on the same data.
     * Conflicts are either based on changes to a key:value pair, but a
       whole table could be locked to mark dependency conflicts.
     * The syncing against disk is normally done first when the database
       is closed or forced to sync; this is when any unused block is
       reused. This gives very high speed.
       (The database could of course be in a state where every
       transaction completion is synced to the disk.)
     * To make this non-syncing secure, the database uses a journal file.
       When something fatal happened to the process using the database
       (power loss, kill -9, whatever), this file is read back and the
       database is restored to the latest state possible.
     * The transaction order is guaranteed; any transaction following any
       failed (ie, broken, not cancelled) transaction will never be seen
       as valid.
     * The database is fast; it is normally no problem to write or read
       several thousand entries per second, if the I/O wait is slow
       enough.
     * The database is unfortunately low-level, there is no high-level
       replicating, memory-only or distributing schemes included. It was
       never inteded to solve these problems, only the speed and
       security.
     * The library is heavily tested by a testsuite, including tests
       simulating power loss and write failures (as in writing the wrong
       data to the database).

  Debianized source version you can find on ftp://ftp.cgs.pl/pub/debian/mird/
  
  eloy
-- 
 --Krzysztof-eloy-Krzyżaniak-----------------------eloy-@-transilvania-eu-org--

                          Moje oczy są oczami wariata
                      Kiedy spotykają się z twoimi oczami