Re: Flexifiles

[Ben Pfaff]

John Darrington <address@hidden> writes:

> On Thu, Jun 08, 2006 at 09:47:36AM -0700, Ben Pfaff wrote:
>
>      I'm beginning to believe that casefiles should not be used for
>      GUI access.  Instead, we should create a new, more dynamic
>      structure for GUI access, one that supports the casefile
>      operations.  For convenience, I'll call it a "flexfile", because
>      it's flexible.  The GUI would use flexfiles where the TUI uses
>      casefiles.  I'd write a wrapper that allowed them to be used
>      interchangeably.
>
> Can we do the API changes for that now?  For the time being, we can do a
> very naive implementation which stores an array of cases on the heap.
> Once we know that it's going to fit in with the rest of the code, then
> we can think about a proper implementation.

Yes, we could do the API changes.  I have too many things on my
plate already, so I am not going to promise to do this.  If you
have time and the inclination, then you are welcome to do so,
although I'd like to look over see a draft of the changes before
they are checked in, if that's all right.

>      This could be easily prototyped with Berkeley DB.  It sounds like
>      you don't know about Berkeley DB, but it's enormously useful, so
>      I'd recommend looking it up: http://dev.sleepycat.com/index.html
>
> I had a look at this site.   If it's as good as it claims, is there
> any reason why we can't implement the final version using this library?

It is as good as it claims.  Berkeley DB is high-quality.  There
is no reason to avoid using it, other than to keep down the
number of PSPP's library dependencies.

It is easy to get lost in all the options that Berkeley DB offers.
I would suggest that a Recno database with mutable record numbers
is the easiest way to create a "flexfile" with BDB.  We shouldn't
need locking or transactions.  At least so far, it's not even
necessary to explicitly name a file to hold the databases--BDB is
able to create temporary files on its own if you give it a null
pointer at database open time.
-- 
"A computer is a state machine.
 Threads are for people who cant [sic] program state machines."
--Alan Cox