Howdy, y'all
I'm brainstorming over a side-project that may require integrating some
kind of DB into Geeqie. I know that having a DB has been on the roadmap
for a long time, so I'd like to implement things in a way that will be
compatible with the usecases that people had in mind.
It feels like a foregone conclusion that SQLite is the right way to go
with this. I quickly looked at BerkeleyDB, but it doesn't have any of
the utilities that SQLite does, so debugging and maintaining things
would likely be a pain.
General things that I depend on, that seem relevant when considering a
DB thing:
— I use geeqie to tag images on multiple machines. I need a way to sync
those tags across machines.
— A lot of times, I use geeqie as an image viewer (and not as an image
sorter/tagger). So it should still be fast using it in that capacity.
The recent change to remember marks (which I use all the time for
sorting/tagging), have made is slow as an image viewer, because it stats
thousands of XMP locations that don't exist.
— There's been a lot of discussion about backwards compatibility and
config file versioning. I haven't paid enough attention, but obviously
those discussions would apply to a common DB as well. Among other
things, that means we'd need to avoid non-backwards-compatible DB schema
changes.
For the curious, my side-project is this: Last year, I wrote some code
that allows geeqie to collapse multiple images into a single common
entry, both in the file listing and in panview. This makes it easier to
look through shoots where some groups of images are close variants of
each other (though the specific meaning of that will change by context).
But these groups need to be saved somehow. This seems like an
even-clearer usecase for a database (since a group is not a file, even
though it could be defined in a distributed manner). That said, I had
some optimization ideas while writing this that I'll discuss in a
separate thread.
--xsdg
