[Digikam-devel] Future plans : 0.9.2-final and KDE4 port...

[Arnd Baecker]

On Tue, 12 Jun 2007, Marcel Wiesweg wrote:

> > On Mon, 11 Jun 2007, Gilles Caulier wrote:
> >
> > [...]
> >
> > > This is want mean than DB structure will change in the future. We have
> > > already a list of new informations to host in DB like :
> > >
> > > - Photo informations to perform search of images based on Exif/IPTC,
> > > - GPS info to perform search of images on a map (imaging a bar where you
> > > can query something like "i want to find all pictures taken around
> > > Paris"), - Haar matrix to perform search of duplicate images (
> > > http://scien.stanford.edu/class/ee368/projects2000/project12/4.html).
> > > - Editor Actions List to perform non destructive edition of pictures
> > > (technics used by Nikon NX soft for ex.)
> > >
> > > This is a small list of future informations hosted by DB. Others data can
> > > be add of course and discussion is open about this subject (Arnd...).
> >
> > There is one important decision about the database:
> > Will it be possible to easily add additional fields
> >    - with new digikam releases (eg. 10.1, 10.2, ...)
>
> If you look at amarok, they have had about 20 schema revisions.
>
> We definitely plan to add more database fields. Adding a table with additional
> information is easy, it becomes more tricky if the change makes the database
> incompatible with previous versions. In this case, the application has to
> detect it and refuse to start.
>
> As current versions cannot do this, my current plan is to move the db file to
> digikam4.db (where 3->4 nicely coincides with KDE3/KDE4) and any version from
> now on will be able to refuse to start if it does not understand the schema.
> Users usually do not need to downgrade a version. If they have to, there'd be
> a severe regression which we should have fixed first ;-)
> So the possible missing compatibility (not for all schema upgrades necessary )
> mostly affects beta testers which might have a reason to use a stable
> version. In this case, we will make this clear in the release of beta1 - with
> schema changes only occuring in alpha state, and the option to specify
> different db files in config / on the command line.

Thanks for the detailed explanation - this looks like
a very robust, but still flexible path.

> >    - or even by the user
>
> The problem is that the application at least needs to provide means to read
> and write the added values. If it does not know at all about the nature of
> the data, this will be only very basic support.

Something like this might be possible via KROSS
(which would allow for simple plug-ins added by the user).

But: as you explained above, the new database will be much more
flexible and allow for additional fields, whenever they are
needed. Any new fields would also be accompanied by
code which makes use of them.
So I don't think that addition by the user is really needed.

Thanks a lot (and now I will stop asking about this, to not prevent
you from further coding ...),

Arnd