[Digikam-devel] Qt 4.0 port and new DB backend...

[Marcel Wiesweg]

> Hi all,
>
> Just pointing you about some interressing threads :
>
> In dot.kde.org we have currently discussion about digiKam
>
> http://dot.kde.org/1163972504/1164012311
>
> A kde user point me to use "Strigi" as a new DB backend :
>
> http://www.vandenoever.info/software/strigi
>
> Somebody know it ?

Yes, I have been following blogs (planet.kde.org) and read the akademy 
presentation PDF.
If you remember, long ago Scott Wheeler planned an extensive search framework 
called "Tenor" which would include contextual linking. There was never much 
more than plan and thoughts for this project. Robert Cappuccio started to 
write "Kat", a file indexer similar to Beagle, but this project also died for 
reasons unknown to me.
Now, Jos van den Oever has written another indexer, it seems to be lightweight 
and pragmatic to make things work. Technically, there is a crawler which 
indexes your local files, including metadata, storing information in a 
database, and an interface to query this information.

Assuming that strigi will provide desktop search functionality for KDE4, one 
thing is to integrate digikam's information into the strigi database, I mean, 
provide some module for strigi so that it can access all the information 
digikam knows about its photos, can index this in its database and provide it 
to the users of strigi's search interface. I consider this to be integral 
part of digikam's desktop integration.

A pretty different thing is the suggestion to use strigi's storage as the 
backend for digikam. I could not find anything resembling an API 
specification for this task. We should talk with Jos about this, as we have 
no idea how strigi is layed out internally, but I have some doubts:
Digikam's db is more than indexing files. It contains
- the tag tree structure
- information (icon, collection) about tags and folders
- internal references: the image table references an internal structure, the 
tag tree
- stored searches

Moreover, for the planned versioning of files (the implementation of which 
still needs a lot of thought ;-) ) we may need contextual links between 
files, for the planned storing of actions we need to store this in db.
If we take Amarok as an example, it provides "advanced file tracking" - 
identify files even if renamed or moved, media device integration - allow 
removable media in your collection, this needs even more contextual 
information.

So these are our needs. We have to store a lot of information which may ("may" 
because I am not familiar with strigi) be beyond the scope of a file indexer. 
In any case, using or not using strigi as backend is independent from its 
integration in digikam.

Marcel

>
> In kde-extra-gear mailling list, a thread have been started about port all
> extragear applications to QT4 :
>
> http://lists.kde.org/?l=kde-extra-gear&m=116342817101871&w=2
>
> Marcel, Paco, let's me hear your viewpoints...
>
> Gilles