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

[Thomas McGuire]

Hi,

On Sunday 28 March 2010 01:58:19 Maciek Zarzycki wrote:
> 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'
> * 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. 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.
> 
> [Framework]
> The framework should be written in c++. It should provide a dialog allowing
> user to specify input/output files. 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.
> 
> [Plugins API]
> All plugins should implement following API:
> * execute() method to run plugin's action. It should take list of URLs
> containing input/output files.
> * 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.
> 
> 
> 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.

That sums it up pretty well. I'd like to add that it would be great if it 
would be possible to export/import _everything_ to/from a single archive file; 
with this, users could simply use that file to move all their data/config 
between machines, for example when reinstalling or making a backup.

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100328/cdb22ae2/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/