[Kde-imaging] Digikam + Kipi + Export and/or Sync to web services (and other such stuff)

[Colin Guthrie]

For reference, another IRC log I had with yet another very helpful 
akonadi guru :)


<coling> Are you about?
<coling> (by "guys" I mean akonadi ninjas)
* coling realises that ninjas are good at hiding ;)
<tokoe> coling: do you have any question?
<tokoe> so what is going on in essen?
<Bille> tokoe: everyone else is eating
<Bille> i am not because i just had to make an emergency trip to the 
local dentist and am anaesthetised.
* fosterfeld has quit ("Frank has left the building.")
<tokoe> Bille: :(
<tokoe> Bille: get well soon!
<coling> tokoe, yup :)
<coling> We're on a coding sprint in italy for KDE imaging right now
<coling> and we're looking to integrate our remote image sync systems 
using akonadi.
<coling> I just have a quick question about "accounts".
<tokoe> coling: what is the remote image sync system about?
<coling> tokoe, well for background:
<coling> in kipi (KDE Image Plugins)
<coling> we have several "export" plugins that are all separate and distinct
<coling> Each one implements interaction with a given system.
<coling> e.g. we have one for flickr, one for gallery, one for picassa etc.
<coling> The UIs are all different
<coling> and any shared code is, well, not shared :s
<tokoe> ahh ic ;)
<coling> So we wanted to build it on Akonadi, which can cache the remote 
side quite nicely making working with large remote collections quite nice.
<coling> But I'm just a little confused about how accounts work.
<coling> e.g. in IMAP
<coling> You have multiple accounts, but presumably just one IMAP 
resource/agent?
<coling> Do you create multiple instances of this resource but with 
different arguments?
<coling> (e.g. credentials)
<coling> And if so how is this stored in the akonadi cache (i.e. what 
differentiates one IMAP resource from another? - is it the 
name()/setName() that is the differentiating factor?)
<coling> tokoe, FWIW I spoke to till the other day about this a little, 
I posted my writeup (and an IRC log here: 
http://thread.gmane.org/gmane.comp.kde.devel.imaging/7073
<coling> But how "accounts" would work is still a gap in my knowledge :) 
I plan to start dev tomorrow and sunday.
<tokoe> coling: well, normally you would have one agent/resource per account
<tokoe> coling: so for two imap accounts you would start to instances of 
the agent_imap with different configurations
<coling> tokoe, good, that's what I thought :)
<coling> And do we name them differently? Is that how the akonadi 
service knows which one is which in terms of caching and available 
collections etc.?
<coling> so one would be "Flickr account 1" and another may be "Flickr 
account 2"
<tokoe> coling: each instance of a resource has an unique identifier and 
can have a display name that can be set by the user
<coling> Ahh cool. So when you first create a new "account" you 
basically assign it a UUID?
<coling> And it's up to that app to keep track of it's own accounts and 
how they map to Akonadi UUIDs? (and set the name for UI display etc).
<tokoe> coling: yes, you'd use the AgentInstanceCreateJob from 
libakonadi to create a new instance
<tokoe> coling: exactly, the application should store the uuids of the 
agent instances it has created to access/manage them later
<tokoe> coling: however a central idea of akonadi is sharing the data, 
so when one app creates a new instance, it is visible for other apps as well
<coling> tokoe, right - makes sense (and how we would want to do it too!)
<coling> We will have to create an "account manager" that will list all 
the accounts associated with the "image export resources"
<coling> But we would want other systems to be able to access these 
accounts to.
<coling> With that in mind how would you recommend we store credentials 
(API keys, username/passwords etc.) such that another app could load 
that resource if need be?
<coling> (I apologise if this is in docs etc. but I will be getting very 
dirty with the actual coding tomorrow I hope and this is good primer as 
we have a few people here and I'd like to split up jobs appropriately if 
possible - we'll all be learning tho'!)
<tokoe> coling: the resource is loaded by the akonadi system, so the 
resource is the only app that knows how to access the credentials
<coling> Ahhhhhh, right...
* coling was thinking of the resource as just an accessor class rahter 
than something that will manage itself.
<tokoe> coling: that was in former times :)
<coling> Indeed... KResource RIP
<tokoe> coling: no a resource is a real process
<coling> Right... so... hmmm, so a resource would probably use e.g. 
kwallet to store sensitive credentials and would key itself using the 
akonadi job UUID?
<tokoe> coling: yepp
<coling> Cool.
<coling> And is there a way to define a type to the resource?
<coling> e.g. I'd like to create a standard "Image account manager"
<coling> and so list all accounts that have a certain "type" of resource.
<tokoe> coling: well, in akonadi you have collections and items
<coling> Sorry.
<tokoe> coling: collections are like directories and items like files in 
a filesystem
<coling> Yeah, I understand that bit I thinkg.
<coling> I'm meaning higher level than that
<coling> So to use IMAP as an example
<tokoe> every resource/agent provides a so called base collection
<tokoe> inside that collection all data of the resource are located
<tokoe> now every item can have assigned a mime type
<coling> Ahhhhhhhhh
<tokoe> and every collection can have a list of mimetypes that are 
allowed inside
<coling> So we could iterate through all base collections, and list all 
the ones that are allowed to store images for example?
<tokoe> so your flicker resource would create a base collection that has 
image/xyz as content mime type set
<coling> Indeed :)
<coling> OK, I think that's perfect :)
<tokoe> coling: yes, and we have even convenience classes for that...
<coling> wow, free beer too? :p
<tokoe> you can use a Akonadi::CollectionView with a 
Akonadi::CollectionFilterProxyModel that shows only collections of a 
given mime type
<coling> Nice :)
<tokoe> kaddressbook would use that for showing only collections that 
contains vcards, kmail to show the collections that contains mails etc.
<coling> Yeah this would be perfect :)
<coling> I guess this would not apply when creating a new instance tho'
<coling> e.g. in kmail when adding a new mail account.
<tokoe> hmm?
<coling> Or perhaps I've not understood the root collection thing you 
described above?
<coling> Do resources without any instances (e.g. no call to 
AgentInstanceCreateJob) still have a root Collection that we can filter 
in this way?
<coling> I'm thinking when we want to add a new account (e.g. a new 
flickr account) and want to call AgentInstanceCreateJob with the correct 
resource.
<coling> That resource can then present it's own config dialog etc.
<coling> (for API keys and passwords etc.)
<tokoe> coling: no, only running instance processes show up with their 
base collection
<coling> Cool.
<tokoe> coling: yes exactly
<coling> So when we want to create a *new* flickr account, how would I 
list all possible resources?
<coling> (and also how would I hide the irrelevant ones?)
<coling> Or do we just have to "know" which ones are available?
<tokoe> coling: ahh... you have to differ between agent types and agent 
instances
<coling> e.g. Kmail "knows" that the imap resource.
<coling> Indeed
<tokoe> coling: agent types are the types of resources that are known to 
the akonadi system
<tokoe> coling: e.g. currently we have the vcard, ical, imap and 
bookmark agent types
<coling> Ahh OK, so we would add an "image" one?
<coling> And just so I'm understanding, we will implement several 
agents, but they will all serialize to ultimately the same object and 
will ultimately have the same agent type.
<tokoe> coling: you can ask the akonadi system for all available agent 
types with the Akonadi::AgentManager class
<coling> tokoe, you've thought of everything :)
<coling> And presumably to add a new type we just create a .desktop file 
or something?
<tokoe> you'll implement different agents and they so they will all have 
a different agent type, but they all provide data from mime type image/xyz
<tokoe> coling: do you have a checkout of kdepim by hand?
* coling get's one.
<tokoe> coling: lets take a look at a simple akonadi resource
<tokoe> coling: change to the directory kdepim/akonadi/resources/vcard
<coling> (thanks for this tokoe, it's really appreciated :))
<coling> still checking out....
<tokoe> coling: your welcome :) i'm happy if akonadi will help to make 
your life easier ;)
<coling> tokoe, I think it certainly will.
<coling> And I think it will bring a lot of nice integration to KDE 
generally too.
<coling> (nice screensavers from Flickr and Facebook etc. etc.)
<tokoe> yeah :)
<coling> still checking out.... :'(
<tokoe> as you will see, that resource is quite easy
<tokoe> i consists of one .cpp, one .h and a .desktop file
* coling wishes he'd just checked out *part* of kdepim ;)
<tokoe> how the code from the .cpp and .h file works is nicely explained 
on the techbase article written by krake
<coling> Oh cool, /me will read that tonight.
<tokoe> the interesting part is the .desktop file
<coling> Checkout finally complete.
* coling is looking now.
<coling> OK, so the X-Akonadi-* keys are the.... erm, key :)
<coling> so text/directory
<tokoe> so you can see the desktop file contains Name and Comment 
entries, these are use in the dialog where the user can choose which new 
agent he wants to create/instanciate
<coling> Indeed.
<tokoe> the Type says its an resource description for akonadi and the 
Exec has the executable name
<tokoe> X-Akonadi-MimeType contains the list of mime types this resource 
is able to provide
<tokoe> in your case would that be the image types that flickr etc. provide
<tokoe> for capabilities your use Resource as well
<coling> With you :)
<tokoe> as identifier choose akonadi_flickr_agent etc.
<coling> So same as Exec in this case.
<tokoe> the uuid of the instances of that resource will be 
akonadi_flickr_agent_X where X is an unique number
<coling> Ahh right.
<tokoe> coling: depends on how you call your executable, but it makes 
sense to have the same name
<coling> So that's why identifier is not simply Exec
<coling> Yeah. got it :)
<tokoe> i'm away now for half an hour... bbl
<coling> tokoe, this is awesome. Thanks very, very much.
<coling> I'll read krake's techbase article now.

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]