[Kde-pim] The SyncML integration problem..

[Patrick Ohly]

On Mon, 2010-03-29 at 15:19 +0530, Dinesh wrote:
> > On Sunday, 2010-03-28, Dinesh wrote:
> > One of the approaches the looks most promising is better KDE integration
> > for
> > SyncEvolution. Such an integration would basically be twofold: data access
> > (e.g. in the form of finishing the Akonadi backend for SyncEvolution) and
> > runtime infrastructure access (KDE bluetooth pairing, device detection,
> > proxy
> > parameters, etc).
> 
> hmm..... yes , i ll check syncevolution out ASAP ...
> 
> > Patrick has created a prototype of the former and can most likely provide a
> > list (or hints where to look) of things necessary for the second.
> 
> again..ya... just came across this link while googling... would soon
> check it out..

What you want are the patches in the "akonadi" branch. Before you start
working on that, better "git rebase" to latest master.

Regarding platform integration:
      * You could run the GTK sync-UI, but probably you'll want
        something Qt based. There is some work inside Intel on that, but
        the design is not targeting desktops. At least the Qt/D-Bus
        hints in the D-Bus .xml files can and should be shared.
      * System proxy settings: we get those via libsoup-gnome. Not sure
        how well that works in KDE. I suspect that it doesn't use
        libproxy (but not sure).
      * Password storage: we use the GNOME keyring, via its library API.
        Recently there's been some progress on a common D-Bus API, see
        http://bugzilla.moblin.org/show_bug.cgi?id=6319 "use KWallet
        instead of GNOME keyring". Patches to use that API instead if
        the lib calls welcome...
      * Bluetooth: there's a plugin for GNOME Bluetooth which recognizes
        SyncML-capable phones, provides a button for the user, then
        fires up sync-UI to create a config for them. The backend uses
        Bluez D-Bus APIs to detect paired phones, so that part should
        work in KDE.

> > Sascha if I remember correctl you indicated that you most likely won't have
> > time this year to participate in GSOC yourself, do you think you could be a
> > mentor for this?
> 
> Sascha: is it the same person who worked on GSoC project last year to
> provide akonadi agent for syncml??

Yes.

>  it was only yesterday that i found
> out about this GSoC project...( i would like to know more about
> it..(actually svn is blocked in my college, so i ll have to try out
> other ways to get the code, so it might take some time)...)... and i
> was under the impression to drop the idea of the proposal for syncml
> support for akonadi for gsoc this year...( cuz, as per his blog it
> looked nearly over...)so can anyone please tell me about what is
> needed out here??

The SyncML server part (= synchronize with phone locally) has never
really worked. The SyncML client is rudimentary:
      * Several vCard extensions were sent in such a way that they would
        get lost on a SyncML server (need translation to extensions
        understood there, partly done in SyncEvolution "akonadi"
        branch).
      * I suspect that calendar support was basically untested. For
        example, VTIMEZONE definitions need to get into and out of
        Akonadi items somehow.

The client was based on the Funambol C++ client library, which is not as
well-tested against servers as the Synthesis code.

-- 
Bye, Patrick Ohly
--  
Patrick.Ohly at gmx.de
http://www.estamos.de/


_______________________________________________
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/