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

[Kevin Krammer]

On Sunday, 2010-03-28, Maciek Zarzycki wrote:
> Hi,
> 
> I have reread all posts in this thread and I would like to summarize it a
>  bit and propose my solution. Any comments from you are more than welcome
>  :).
> 
> The main idea behind this project is to create a unified import/export
>  dialog for all KDE PIM applications (and perhaps some others). This
>  utility should present following features:
> * capability of handling various types of data as used in PIM applications
> * capability of handling configuration files
> * easily extandible to handle new types of data / applications
> * 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.

> * as easy to use as possible (some kind of matching presented options with
> input files / context in which the utility is used)

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

>  What is more, the plugins for individual actions
>  should be written in interpreted language to allow easy installation from
>  'get hot new stuff' (python or javascript using QScript). What I plan to
>  do is following.

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.

> [Framework]
> The framework should be written in c++. It should provide a dialog allowing
> user to specify input/output files.

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?

> It should present user with list of
> selectable actions to perform. After user selects the desired actions,
>  dialog should run them one by one and present user with some kind of
>  progress notification.
> The framework should also contain helper libraries for import/export tasks
> (like importing/exporting mails for KMail or calendar entries for
>  KOrganizer, generic Akonadi import/export). They should provide Python (or
>  QScript) bindings to be used in plugins.
> 
> [Plugins]
> Each import/export action should be represented by a plugin. If possible I
> would like to have plugins written in Python because of its excellent KDE
> bindings and ease of use. If embedding Python scripts in c++ dialog is
> impossible or too hard to do, plugins should be written in ECMA script and
> used through QScript framework. The plugins should be written in a way to
> minimize user involvement (deduce as much as possible from applications'
> config files). They should use methods from helper libraries delivered by
>  the framework.

For scripting see intro of this mail.
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?

> [Plugins API]
> All plugins should implement following API:
> * execute() method to run plugin's action.

execute() as in return once finished or as in start and signal end of 
operation?

> It should take list of URLs
> containing input/output files.

Depending on what scope a single plugin is intended to have, URLs only might 
not give sufficient context. E.g. when a certain combinations of source affect 
a certain combination of destinations, like when one mail application stores 
account settings into different files for receive and send but the target 
putting both types into one file per provider.

> * progress signal informing about plugin's progress
> * error signal informing about possible error
> * optional cancel slot (?)
> 
> As for selection of actions displayed in the dialog, I was thinking about
>  the 'context' mechanism. The simplest solution would be to specify list of
>  applications that a plugin might be usable for. Based on this, the dialog
>  would choose which actions to show to user.

Assuming actions in "different steps of the process", how does the application 
know which steps are required in which order?

> This is the project I would like to work on. It has some interesting
> challenges in it  that make it interesting for me. Please tell me what you
> think about it. I'll be glad for any possible improvements or different
>  ideas.

It would be a great addition to KDEPIM or more like fixing a major short 
comming.

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.

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/20100328/62baf548/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/