[Kde-pim] GSoC: Easy Import and Export of all PIM data in Kontact

[Kevin Krammer]

On Monday, 2010-03-29, Maciek Zarzycki wrote:
> Hi,
> I have reordered your mail a bit to make answering easier.

> I was hoping that the scripts would go through some kind of audit before
>  being added to ghns.

You are right, didn't think about that.

> Anyway, you are right in saying that it might be too much for GSOC. I will
> drop this and perhaps implement it after GSOC.
> 
> > > The solution fulfilling all the above requirements must be based on a
> > >  plugin architecture.
> >
> > I'd say that is an implementation option not the only possible solution.
> > Wordings like "must be" will have to be defended on basis of clearly
> > specified use cases showing that there is on other viable way of doing it
> > properly.
> 
> That's a good observation. Can you think of other approach that would
>  fulfill the goals of the project (mainly ease of extensibility)?

Another approach could be to create a library or set of libraries which 
include common components for import/export tasks and then build individual 
applications on top of that.
It is less flexible since one needs create new applications (or extend 
exisiting ones) when adding new import/export targets, but it does not require 
to come up with a universal interface right away.

However, if you feel confident that you can do a plugin based approach you 
should do that.
The GSOC result can be a prototype to learn which interfaces might have to be 
changed, so they don't have to be universal yet.

> > I do have a question on "each action should be represented by a plugin"
> > though: assuming again a concrete example, what would such single actions
> > be? How would the host application decide which plugins to load, which
> > set of actions to execute and in which order?
> 
> Initially I was thinking about creating separate plugin for each basic
>  action. For example 'import messages from Evolution' and 'import account
>  settings from Evolution' would be separate plugins.
> Now I think that a plugin should group similar actions to allow for maximal
> code reuse. We might have an 'Evolution' plugin with following actions:
> * import messages - imports all messages from Evolution into newly created
> folder in KMail
> * import account settings - adds accounts from Evolution to KMail
> * import contacts - imports Evolution contacts into Address Book

Ah, ok, sounds good.

> The actions can be implemented as objects having API similar to what I have
> previously devised for plugins, meaning:
> 
> * execute() method
> Because the actions are fine grained and should not depend on each other, I
> think it is enough to pass list of URLs as  parameter. It might be maildir
> directory path for 'import messages' or list of vcard files for 'import
> contacts'.

Ok, this might work indeed.
Or the action/plugin could determine/ask for the import/export set itself and 
have this as an internal state.
You'll only have to pass this into it when you have a separate entity which is 
getting that information.

Passing URLs could be difficult if the target is not fully predefined.
For example when importing account settings would result in creation of 
Akonadi resources. These resources have config files but the name is unknown 
until the resource agent has been "added" through an API call.

> It would be easier to implement it as blocking method, but asynchronous is
> also an option.

Blocking API look easier at first but some implementations might be hard to 
implement synchronous and it is the easy to get into a nested event loop mess.
We had our share of these problems when porting code from traditional blocking 
interfaces to Akonadi's asynchronous API.

> * context property - list of contexts this action might be useful in.
>  Please see below.
> 
> * import/export property - whether it is import or export action
> 
> * progress signal
> * error signal
> * cancel slot
> 
> > I am not sure I understand this correctly.
> > How would the framework know what do list and what does "files" mean in
> > this context? Could you describe an example, e.g. how this would look
> > like when importing from KMail or Evolution?
> 
> The idea of contexts is very simple. Lets assume that we have an
>  'Evolution' plugin which has following actions:
> * import messages - context = kmail
> * import account settings - context = kmail
> * import contacts - context = address_book

Ah, I see.
Plugins in KDE world are usually subscribed by special .desktop files which 
are installed alongside the plugin. This allows applications to list available 
plugins and their features without loading the plugin right away, i.e. loading 
them once the required ones are chosen.

You could come up with a way to describe your contexts in such a file as well.

One important thing to remember is that context will most often be a data type 
(e.g. email), not a special application.

> When ran from KMail, the dialog would know its context is 'kmail' and would
> only show 'import messages' and 'import account settings'. If the dialog
>  was ran from Kontact instead, its context would contain both 'kmail' and
>  'address_book' and therefore it would display all three actions.

Makes sense.

> > Assuming actions in "different steps of the process", how does the
> > application know which steps are required in which order?
> 
> I'm afraid I don't understand the question. Could you explain it a bit
>  more?

I wasn't sure how "big" an action is. E.g. if an action would only be "convert 
mbox to maildir" the application would need a way to create a sequence of 
actions for the full import/export task.

After your explanation above, i.e. an action being the full procedure, this is 
no longer relevant.

> > However I would advise to create a set of scenarios first and then
> > evaluate how suggested concepts would solve each of them.
> >
> > The time limit in GSOC allows us to choose the scope any such project
> > will be required to solve, e.g. perfectly handle a specifc scenario,
> > optionally do another, not care about certain special cases, etc.
> 
> The aim I want to achieve with this project is to create a unified
> import/export experience. Right now, every KDE PIM application has its own
> mechanism for this. During GSoC I would like to implement the generic
> framework and port import/export actions from Mail, Contacts and Calendar
> components of Kontact. As a bonus I would also create aggregating
> import/export action for Kontact that would handle importing/exporting of
>  all data using single archive.

Very good.
What I was suggesting though is to create a number of example scenarios or use 
cases and then evaluate ideas against them.

For example:
user has a copy of their $HOME directory from a previous installation and 
wants to import data and settings without copying the files to the current 
$HOME first.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100401/ea341829/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/