<br><br><div><span class="gmail_quote">2007/8/31, Marcel Wiesweg <<a href="mailto:marcel.wiesweg@gmx.de">marcel.wiesweg@gmx.de</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> I think Multiple Comments is essential. But also comments need to be<br>> qualified more than just a simple text stream. Gilles mentioned 4<br>> strings to be stored but I'm not sure what they all are. My suggestion
<br>> would be:<br>>  * Source<br>>  * Who/Author<br>>  * Language<br>>  * Comment<br><br>Gilles, was that what you meant with 4, a table for multiple comments with<br>four columns like the ones above?</blockquote>
<div><br>I thinking 4 (more if you want) different comments as UTF-8 strings. Nothing special about that. We can use like we want, for example to store text in many language, or text come different photographers.<br><br>You course this still to define more. What the advantage to use a table we host all strings against 4 separate strings ? 
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> Here the Source would 99.99% of the time be "Digikam" but hopefully this
<br>> interface can be exposed via e.g. Facebook/Flickr via Kipi plugin and<br>> under these circumstances the Source would be set accordingly. Language<br>> I think should be optional seeing as external comments may not have this
<br>> information associated with them.<br>><br>> > - rating<br>><br>> Tags, (as Gilles also pointed out). With the addition of a "region"<br>> attribute (simple rect is probably sufficient here 
c.f. Facebook -<br>> simplicity wins) as per <a href="http://bugs.kde.org/show_bug.cgi?id=146337">http://bugs.kde.org/show_bug.cgi?id=146337</a><br>><br>><br>> And another new one for you:<br>> - key/value pairs
<br>><br>> Some form of generic key/value pair storage system for every image,<br>> album and tag. This would be to allow 3rd party plugins via kipi store<br>> important information/configuration paramaters. Actually, possibly more
<br>> sensible is a blob of data instread, in which we can store an XML<br>> kconfig dump although this would not allow easy searching... (e.g. it<br>> would be quite useful for a kipi plugin to say "give me all images with
<br>> foo = 42".<br>><br>> This needs more discussion but I've often mentioned it in the past so<br>> not a bolt from the blue.<br><br>We already have a table for this. If libkipi required a method to store
<br>String/String pairs for an image, it would be easy to provide.</blockquote><div><br>Colin, you will be happy to implemente it (:=)))<br><br>Gilles</div></div><br>