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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
