Hi,

Glad the 0.1.3 release is out and impressed with Seb's timing :p

Now I think it's time to introduce this concept again!!!

The way I see things is to create a libkipi API that achieves two things
(this is my personal requirements I'm sure other people have other ideas):
 1) Remove (or make optional) all interfaces that rely on file paths.
 2) Allow the host application to store additional info about
collections/images.

For 1) I see this as important for working with e.g. "dynamic"
collections like the Tags views in digikam or a saved search etc.

For 2) this is to provide e.g. key/value storage system for collections
and images such that it could be used e.g. to sync a folder to a remote
location (be it a folder or PHP Gallery or Flickr etc.)

Fine, both of these are (conceptually at least) quite simple.


Now here is a small idea I've been fiddling with over the last couple of
days and would like some feedback (it is related to the above so bear
with me!)

I was trying to think of how to implement the basic requirements for a
"sink" for the sync plugin (here sink is so named as per the source/sink
terminology where the host application is the source).

I realised I would need a way to create an album, add images to it etc.
For viewing purposes it would need to return a list of albums and images
and grab thumbnails etc.

In the end, I realised that the API to access a "sink" was startlingly
similar to to the libkipi interface in general!!

With some careful thought and a bit of fore sight, the modifications to
libkipi coming up and the implementation of the "sink" base class could
be made to be compatible.

What would this achieve? Well, in principle, this would allow you to
write a bridge of some sort that would allow any "sink" to act like a
kipi host application and thus use any kipi plugin with that host!! This
would allow e.g. calendars to be created with your PHP Gallery sink, or
a slideshow to run with you Flickr account..... Some quite interesting
things as I'm sure you can imagine. I would not expect everything to
work (e.g. batch modifications etc. may not work (or for that matter be
sensible anyway))

What do people think about this idea. I quite like it personally, but
then I'm biased. I may also have missed some fundamentally important
issues at play here!!


As a note to Seb in particular, can you image being able to wrap up
libgpod in a libkipi style wrapper (e.g. implement the "iPod" as a sink)?

Other sinks i would like to implement (or have someone implement!) are:
 * PHP Gallery 1/2
 * Flickr (maybe, not sure about the login procedure)
 * PicasaWeb
 * Other web based galleries
 * Generic KURL location
 * iPod

Feedback is most welcome.

Col

-- 

+------------------------+
|     Colin Guthrie      |
+------------------------+
| kde(at)colin.guthr.ie  |
| http://colin.guthr.ie/ |
+------------------------+
_______________________________________________
Kde-imaging mailing list
Kde-imaging@kde.org
https://mail.kde.org/mailman/listinfo/kde-imaging