From: Don Allingham, Sat Nov 29 23:26:57 2003
> On Sat, 2003-11-29 at 22:55, Alex Roitman wrote:
> > Well, we could pack everything into directory and then compress
> > that directory into a single file, just like OOo does it...
> This could probably be done. However, it would require that we would
> need to constantly extract image files and thumbnails from the
> archive. I'm not sure what type of impact this would have. Then
> management of temporary files would get to be a problem, especially
> when someone wants to use an external viewer.
[WARNING: verbose brainstorming ahead]
IMO, storing images and other binary globs *within* the GRAMPS
file/store is the wrong approach. Ideally, the perfect genealogical
application *suite* has a main genealogy app, with supporting apps
that manage images, publishing, cemetery info, census, etc., *each*
with it's own file format. The main app supports links to data formats
of the others, but it's up to the user to re-link if name/structure
Most professional graphics layout software works like this. You have a
central app that does the layout, but all the globs are links. When
they break or are updated, you are prompted. AutoCAD, too, can
reference data files of various other mediums. If a link is somehow
broken, it first checks the same directory for a file of a matching
name and loads it if found. This is very convenient for packaging and
transmitting whole data stores since the data integrety is maintained.
I'm frankly very fearful of any app that tries to stash globs of
different file formats into one big wad. Sure, *we* all know it's just
a gzipped directory structure (now!), but I think the differentiation
in file extension would be as helpful for managing app development as
it is intuitive for the user. Imagine a structure:
Hall.gramps <= genealogy db
Hall.ged <= exports...
./www/index.html <= exported web site
photo1.tif <= images...
hall.gallman <= image gallery manager (future :)
PerryCo.cemman <= cemetery database manager (future :)
1880.censman <= census database manager (future :)
book1.pp <= Passepartout GNOME publishing app
invite.stw <= OO.o writer document
ToDo.sxc <= OO.o spreadsheet
Each part does only what it's good at, as small, atomic pieces. And I
think this would be clear enough for the average genealogist to
manage, too. Better the file system to manage the truly distinct
objects than an app interface. I also think an app storing objects
within its file that it can't edit is wrong. Unless GRAMPS envisions
being able to edit images, layout, or webpages (even using embedded
apps) it shouldn't store anything within its file format that it can't
fix without a dependent app.
> The other concern is when we move to a real database, can we work on
> a database that has been added to an archive?
You're talking about a file set that properly references singular
atoms in a many-to-many relationship, right? Family Origins used a
collection of files, all with the same name, but different extensions.
The open dialog always filtered for only one of those, so it was clean
for the end user. Except when you wanted to move databases around, and
then it got VERY complicated. (Imagine databases named "hall",
"hall1", "hall-old", "hall-temp", each with 18 files, when you want to
exchange names between two dbs.)
Wouldn't the bottleneck in having all the files in one tarball be the
gzip/tar each read/write? (I can't imagine file I/O or data updates in
RAM would be.) Couldn't this happen transparent to the display
changes? Surely no one could edit records quickly enough to get ahead
of the disk writes. ("Please wait... previous transaction must be
processed before completing this one.") Do many small files g(un)zip
faster than a few big ones?
It might be interesting to investigate the actual data connectiveness
that a genealogist really needs. I'm certain individual relationships
and source connections to them are db-proper. But I'm not so certain I
need photos, cemetery rubbing scans, or birth certificate scans
connected as a db would do it. I can barely imagine an instance where
one image would be connected to many records. Perhaps an odd photo of
several non-direct-family individuals would be referenced by each of
their records. But couldn't this just be a single link to a file, and
then db references to that link?
Well, I'm definitely out after curfew on the above but I thought it
might help to elaborate on one user's opinion. I've been doing
genealogy for a while and all I really care about is that the record
data is clean, the source references accurately maintained, and the
report/drawing/export flexible. The rest of the features found in apps
like Family Tree Maker I find cutesy appendages useful only for
marketing the product but little assistance (and often annoyance) in
the practice of quality genealogy.
Most of us genealogists keep collections of paper files in cabinets
around the house and prefer to go shuffling through it once in a while
in hopes of connecting more of it together. So I'd bet conceeding file
management on disk to a big db even more of a hurdle for the user than
the developer anyway.
Steve Hall [ digitect@... ]