[KimDaBa] Re: kimdaba: why not join forces with gwenview

[Eivind Kjorstad]

On Monday 16 February 2004 16:05, Aurélien Gâteau wrote:

> > Yes, but for another reason.  digikam plugin interface currently
> > leaks the implementation of albums is a folder.  But with an
> > adaption (or redesign)  there no reason why the plugins system can
> > be extended adapted to fit the need of kimdaba, digikam, gwenview

> Sorry, didn't understand the "leak" part :(

What Jesper is saying is, assuming I understood him correctly (and I 
hope the chanse of that is fair);

Within a program, there exists different concepts, such as "Album" and 
"Picture". These concepts are program-concepts, in principle, with a 
clear separation between implementation and design, it matters only 
what properties they have, that is, what information do they store, and 
how can we interact with them. It *should* not matter how they are 
implemented.

Let me give an example.

A "Album", migth be considered as having, for example, a "name", a 
"creation date" and a collection of "images" that belong in the album. 
It migth have functions for adding images to it, listing or showing 
those in it, reading and setting the name and so on.

The thing is, none of those (should, in an ideal world) depend on how 
the program actually implements them. One program migth use a 
SQL-database and store the album as a set of records in a set of tables 
there. Another program migth make a folder on the filesystem and store 
information about the album there. 

But as a user of the program, or, like in this case, someone who wants 
to interoperate with the program, this should not matter. You need to 
know "The program knows about albums. The albums have 'names' and they 
contain a collection of images". You do NOT need to know where or how 
this information is stored or otherwise how the program does it's 
internal stuff.

Jesper says that the interface *leaks* the implementation-detail that a 
album is a folder. That is; in an ideal world, it shouldn't matter how 
exactly albums are stored, only what to do with them. But users of the 
digikam plugin-system *DO* get exposed to the fact that digikam 
actually implements albums as folders in the file-system. A fact they 
normally should not need to concern themselves with. Probably this will 
create problems when interfacing with other programs who, though they 
migth have a corrpesponding "album" object implements this in a 
different way.

Kimdaba, for example, has no "albums" per se, but has concepts close 
enough that it'd be no huge deal to expose an api from kimdaba that'd 
give access to "album"-like features. Kimdaba, however, does *not* and 
would *not* do this by collecting the images which belong in a album in 
a given directory. And it'd function poorly if the other program 
insisted that not only do albums have to have these properties (that's 
fine) but they have to get them by being implemented in *this* precise 
way.

I hope that I managed to describe the general idea clearly enough here, 
and that I did indeed understand Jesper correctly.

Sincerely,
	Eivind Kjørstad