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

[Maciek Zarzycki]

Hi,
I have reordered your mail a bit to make answering easier.

> > * user should be able to download new features from 'get hot new stuff'
> 
> I wouldn't put that down as a kind of requirement. IMHO this is more like
> nice to have or after GSOC stuff.
> 
> While I agree that scripability or even script language based plugins sound
> like really powerful ways of making the tool flexible and long time usable,
> I am also quite concerned about security implications.
> 
> A script performing import operations on Akonadi will either have to very
> limited on what itself can do (e.g. only operate on collections passed to
> it by user controlled portions of the app). If the plugin can decide where
> to put e.g. emails it could decide to put them into the system's outbox,
> making it a perfect spam tool.
> (it could do the user chosen import on the side to make this less obvious,
> trojan style)
> 
> Fullfledged language environment like Python might be hard to sandbox, i.e.
> making sure they can't create TCP connections on their own, e.g. for
> harvesting a user's Akonadi setup for email addresses and sending them to a
> spammers host.
> 
> I think the Plasma people have a special, restricted, subset of their API
> for use with downloadable widgets/engines to minimize the impact of this.
> 
> I am not saying that this can't be done for an import/export framework as
> well, but I am not sure this can be done in the limited timeframe of GSOC.
>
I was hoping that the scripts would go through some kind of audit before being 
added to ghns.
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)?
 
> 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

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'.
It would be easier to implement it as blocking method, but asynchronous is 
also an option.

* 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

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.


> 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?


> 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.

Cheers,
Maciek
_______________________________________________
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/