Author: Joe Barr
Note that Rekall does not include an RDMS — it’s only a front-end. Drivers for MySQL, PostgreSQL, and XBase are included in the GPLd version. Also included is the ability to design, display, and execute tables, forms, reports, and queries. Database creation and access rights are controlled by the DBMS, not by Rekall.
I opted to use the MySQL driver. After installing and configuring MySQL 4.0.18-32 using Yast2, I was ready to give Rekall a whirl.
When you start ReKall for the first time you must decide if you want to use an Access-like multiple document interface (MDI) or a single-window document interface. You’ll also need to tell Rekall where to keep its files and what RDMS you’ll be using.
I recommend reading the through Rekall Handbook prior to embarking on your Rekall adventure. It can save you hours of time and it’s very easy to get to: just press F1. I wish I had.
I began by creating a new database, then designed a single table for it. Table design is easy and straightforward in Rekall. The image below shows the design form just prior to saving the new table. The only part that gave me a problem was the primary key, and I could have avoided that problem if I had just read the help prior to starting.
According to the Rekall help pages, Rekall’s notion of a primary key field for MySQL is an alias for “a (32-bit) integer column which is marked with the MySQL primary key and auto-increment attributes.” I spent a couple of hours looking for a way to auto-increment before learning I didn’t have to. Read the Handbook.
Once I had cleared the primary key hurdle, the rest of the table design was a piece of cake. Rekall’s table design tool supports integer, float, date, time, datetime, string, binary, and Boolean column types. I only needed string columns to hold the name, address, and telephone numbers in the table.
Next I created a form to use to view, enter, and update the table. A form is not strictly required, since you can accomplish the same thing simply by asking Rekall for a view of the table data, but that can get a little unwieldy when the table consists of more than just a few columns. Forms can help make sense of the data and let you focus on a single row rather than on a range of rows from the table. They can also make table data entry more intelligent.
I took advantage of the Rekall form design wizard by selecting “Create new form with wizard.” It was as easy as selecting all the columns in the table to be displayed, a general layout, and command buttons to be used. As you can see from the image below, my form ended up having navigation buttons for the First, Previous, Next, and Last rows. It also had Add, Save, and Delete functions.
With my new form in hand, I began to populate the table. I entered 15 or 20 names in the database and as I did so I began to think about how I would want to use the database. Searching for a phone number, sure. Printing mailing labels, check. Perhaps adding more personal info to the table and tracking important dates. If so, I’ll want reporting based on the current date to alert me of upcoming events.
The GPLd version of Rekall appears more than capable of handling all my needs with this simple database. In fact, it can do all that and quite a bit more that I haven’t yet explored. The form and reporting functionality is quite extensive. Scripting is supported using Python, and there are plans to add JavaScript support in the future.
Project viability
I wrote to Mike Richardson to check and see how the Rekall project is faring and ask if it is viable. Mike replied, “Certainly seems to be (well, I would say that, wouldn’t I :)”
He added:
We are currently at release 2.2.0-Beta4, should be 2.2.0-final end of this
month unless someone finds a real nasty. 2.3.0-Beta0 is available, this is
the bleeding edge (should be no problems running forms, etc., but some design
stuff is broken).It is known to build on Mdk91/92, Suse 82/90, and Rh 80/90. Suse are including
it in Suse9.1, and it is also included in Mandrake Cooker. People have
working builds for Debian (not sure which version), Gentoo (and some others,
can’t remember the complete list offhand) and I have built and run it on
Mepis and Fedora Core 1. One guy says he is pretty close to having it running
in OS/X with the KDE libraries.So, as far as I’m concerned, its rock-and-roll.
How it became GPLd
I asked Mike what led him to become the GPLd Rekall project leader. He provided the following history:
I started “kbase” (for want of a better name) in about May 2000, because (a)
katabase (the then attempt at a KDE database f/end) looked to be moribund and
(b) I had some ideas. I developed this over the period to the end of 2001, at
which point I approached theKompany, and they picked up “kbase” and me.Actually, the trigger for this was an announcement from theKompany just
before Christmas 2000 (about KDEDB, a database layer for KDE, now defunct).
Had I gone on holiday a week later I’d have missed it and released “kbase”
as GPL just after KDE went to KDE2 in January 2000. Such is the roll of the dice.theKompany had just about started a database front end, named “rekall.” After
some attempts to merge the two pieces of work, my code base displaced their
original work — I was quite a lot further advanced than they had been.I continued to work for theKompany through November 2003, when Rekall was GPLd.
I had been thinking about this for some time. The user base was not
growing fast enough to support the development needed, so I felt that it
should either be GPLd, or go under to Kexi or Knoda or GNUe or whatever.FWIW my analysis was, roughly, that the cost of migrating Access (or whatever)
to Rekall was too high in relation to other costs. Word migrates pretty
easily to OOo, ditto Excel; email, well, pick your client, ditto browsers. But
in the case of Access, it’s a reimplementation job, with all the associated
costs. I’d like to think that one day these costs become worth it, but I
reckoned it was too long to wait. I argued this point, and Rekall was duly
GPLd.The commercial rights to the code were retained by myself, theKompany, and John
Dean (who did the Windows port and much of the DB2 driver). The drivers that
map to commercial databases are not GPLd (currently, DB2 and (I)ODBC). We
would like to make some money from them, and if people can afford the likes of
DB2 then I figure we can get some crumbs from the table 🙂
Conclusion
Rekall is usable today, but it’s not up with the best of the proprietary world in terms of ease-of-use or feature set just yet. But given its current stage of development, its affinity with the major Linux distributions, and the fact that it is now GPLd, it looks certain that Rekall has a bright future ahead.
