[Kde-imaging] RFC: next kipi & co. generation

[Colin Guthrie]

Gilles Caulier wrote:
> Jain have added a new method to get virtual Tags folders like Physical folder 
> from host database. i think he have used this methods into Flickr Plugin. In 
> digiKam 0.9.0, the kipiinterface support this method and need to be tested 
> indeep. 

snip.

> In libkipi, there is an important wish about to give a tree folders list if 
> the host support album == folder. I think we must fixed this point for the 
> next release.
>
> Aurelien, I'm sure you libkipi with album==folder. What do you think about?

The above two points to me seem like they conflict and it would be
better to standardise.

Personally I would prefer if the host application completely abstracted
the fact that and "album" can just be a folder on disk. IMO the plugin
should not know where to get an albums folder.

If Albums and Tags are treated differently then it means that any kipi
plugin may have to handle them differently.

To me it would make more sense to have the general concept of "Albums"
generically and perhaps have a type of album for specific handling e.g.
"Standard, Tag, Search" could all be Album Types.

Now I may be overlooking something here so I'll explain the thought
process behind this in the hope that someone can point out where I may
be going wrong.

In the Gallery Plugin, I want to be able to store preferences against
individual "Albums" and "Images" (e.g. "Sync this album to Gallery "My
Gallery" in Remote Album "My Digikam Photos"; or "Exclude this Image
from Sync." etc.).

The Kipi API (to my knowledge) does not support such a generic
preferences scheme, so what was suggested to me is that I could use the
Album's folder name as a key in KConfig style configuration file and the
Image file name in a similar manner. This is OK, but it will only work
for Albums where Album==folder. Therefore I could not Sync e.g. a Tag to
a remote gallery.

Personally I feel that *ALL* "folders" supplied to a Kipi Plugin are
virtual and that e.g. view of Albums are no different to views of Tags etc.

In addition, a kipi plugin should be able to hook into a KConfig like
interface for each Album/Image (where in this example an Album could be
an Album/Tag etc.)

Does this make sense? What am I missing (there /has/ to be something I'm
missing!!!)

> In libkipi, i would to add 2 new virtual method to set/get GPS position 
> (altitude, longitude, and latitude) to set/get this informations from the 
> host database. In digiKam will not support yet this informations, but in the 
> future we will do it. These new methods will work exactly like set/get 
> orientation methods do.

This seems like a very specific method to deal with a specific plugin,
and doesn't seem to me to be too future proof (just the first impression).

Is there no way to achieve this generically? e.g. both of these methods
(GPS pos and orientaion) relate to editing the information that can be
stored in an EXIF tag (AFAIK!). Can these methods be generic such that
dealing these bits of data becomes effectively an edit operation on the
EXIF and then just have a way to tell the host application to re-read
the data (e.g. invalidate it's cached version of the data).

I am using EXIF as an example here as I know that this may not apply to
all image types, but hopefully the more knowlegable people in this area
can see the point I'm trying to make.

Just a thought.

All the best

Col.