[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] synching framework in kde
From:       "Maarten Stolte" <maarten.stolte () veronica ! nl>
Date:       2002-01-25 8:12:18
[Download RAW message or body]

This seems rather cool indeed, what i'm mostly thinking is that the
connector architecture needs to be simple, very simple, so people can easily
script an input connector for KitchenSync from MyBookmarks, and other
people, like the konqueror developers, but maybe also Kmerlin and Kvirc can
build output plugins to get those bookmarks into their apps.

Maarten
----- Original Message -----
From: "Nick Papadonis" <nick@coelacanth.com>
To: <kde-pim@mail.kde.org>
Sent: Thursday, January 24, 2002 8:32 AM
Subject: Re: [Kde-pim] synching framework in kde


> Cuendet JeanEric <JeanEric.Cuendet@tetralaval.com> writes:
>
> > > KitchenSync could imho be a central place connecting 'things',
> > > everything from a palm to kmail, to .Net's MyFavoriteSites(?) to
> > > Konqueror's bookmark manager. These connections should come
> > > as plugins,
> >
> > That's a VERY good idea. I think that there should be connectors that
> > Input/Output common types of data: CalendarEntry, AdressbookEntry, Mail,
> > NotesEntry, etc...
> >
> > This could lead to a great architecture where each plugin would be able
to
> > speak to each other in the following way for example:
> >
> >
> >
> >  -----------       -------       --------------
> > | PalmPilot | <-> | KSync | <-> | phpGroupWare |
> >  -----------       -------       --------------
> >  -----------------       -------       ----------
> > | Exchange (IMAP) | <-> | KSync | <-> | KDE apps |
> >  -----------------       -------       ----------
> >
> This is close to my RFC posted a little while back.
> All comments welcome.  I might need to elaborate in some areas, please
> point these out.
>
> ------- SNIP --------
>
> RFC: SYNCRONIZATION IN KPIM
> VERSION 0.02
>
> 1.0 Purpose and Audience
> Anyone intending to synchronize data with a device or service to
> the KPIM data store.
>
> 2.0 Background
> Currently various KPIM synchronization methods are available in the
> KPILOT package.  The current implementation has worked well when a
> wide array of services and devices were not available to the consumer,
> however this has recently changed. Synchronization clients now include
> PDAs, mobile phones, or even remote PIM services like Yahoo.  For this
> reason it would be desirable to eliminate duplicate work developing
> code for synchronization and steer development toward well tested
> interfaces to these services.
>
> Right now, methods are implemented in the form of conduits using
dissimilar
> implementations for interacting and synchronizing between PIM
> applications and services/devices. Synchronization is tangled into the
> particular service/device being synchronized; for example the KPilot'ss
VCAL
> conduit only synchronizes with the pilot-link API and has no
> abstractions to use a different mobile device.
>
> 3.0 Overview
> 3.1 KSYNC
> With a solid and tested synchronization library, adding new devices to
> PIM applications becomes much easier.  The developer will only need to
> develop and test interfaces to new services.  Synchronization libraries
> will be certain and tested.
>
> KSync should be a running process for synchronization of services with
> the KPIM data store.
>
> 3.1.1 Functional Requirements
>       - Should facilitate the ability to allow plugins
>         for each service synchronized.
>
>       - Should be a standalone process invoked by the user or an
>         event from a plugin.
>
>       - Should provide the API and ability to synchronize
>         various PIM data between services and the KPIM data store.
>
>       - Should not provide the ability to directly interface
>         with services such as mobile devices.  This will be provided
> by Ksync conduits for specific devices.
>
> 3.1.2 Implementation
> Ksync would interface with different plug ins.  Communication with the
> plugins can be accomplished via DCOP.
>
> Example plug ins:
>  - Korganizer Plugin : Would make appropriate DCOP calls to Korganizer
>        to add or delete records.  This way operations
>        are updated real-time in Korganizer.
>        Korganizer itself would make appropriate calls
>        to the 'data proxy' and insert records in the
>        KPIM datastore.
>  - Palm Plugin      : Would use the pilot-link library to retrieve
>        and set records in an attached Palm Pilot.
>
> Each plugin would be a seperate process using DCOP or some form of IPC
> to exchange data.
>
> 3.1.3 Data Flow
>
> DATABASE SERVER <-- Set Cal Data --- KORGANIZER APPLICATION (using data
proxy wrapper)
> DATABASE SERVER --- Ret Cal Data --> KORGANIZER APPLICATION
>
> KSYNC <-- Ret Changed Records? --- KORGANIZER PLUGIN
> KSYNC --- Set Changed Records? --> KORGANIZER PLUGIN
>
> KORGANIZER PLUGIN <-- IPC Ret Cal Data --- KORGANIZER APPLICATION
> KORGANIZER PLUGIN --- IPC Set Cal Data --> KORGANIZER APPLICATION
>
> KSYNC <-- Ret Changed Records --- PILOT-LINK <-- PALM PILOT
> KSYNC --- Set Changed Records --> PILOT-LINK --> PALM PILOT
>
> _______________________________________________
> kde-pim mailing list
> kde-pim@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-pim
> kde-pim home page at http://pim.kde.org/
>


_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]