Re: [Opensync-devel] SyncML plugin

[Patrick O. <pat...@gm...>]

On Fr, 2010-12-17 at 19:36 +0530, Dinesh wrote:
> Hi,
> 
> On Fri, Dec 17, 2010 at 2:23 PM, Patrick Ohly <pat...@gm...>
> wrote:
>         On Do, 2010-12-16 at 23:14 +0100, Quentin Denis wrote:
>         > Well, it seems quite obvious for me that direct syncing
>         between the phone and
>         > another group-member should be possible. That is why OBEX
>         seems necessary to
>         > me, or how should I understand how libsynthesis is
>         implemented in practice? A
>         > contact of mine, called Dinesh, has quite a good knowledge
>         about this,
>         > especially since he wrote the syncml-plugin for
>         syncevolution recently.
>         
>         I'm not sure what Dinesh really said about his involvement,
>         but he did
>         not write a SyncML plugin. SyncEvolution already supported
>         direct
>         synchronization with phones via SyncML/OBEX/Bluetooth before
>         Dinesh got
>         involved. He focused on adding Akonadi support (based on a
>         prototype
>         backend that I had written earlier) and a KDE GUI. 
> 
> 
> I kind of dont understand  what went on and really don't know what to
> say here, so, Firstly I totally I agree with what Patrick Just said.

I'm sure it was an entirely benign misunderstanding. Also don't
understate your own work. Without it, there won't be Akonadi and KDE
support anytime soon because I myself cannot cover everything.

I decided to keep the OpenSync list on CC. The question about OpenSync's
design and SyncML plugin came up, so perhaps people here are interested
in the status and internals of other projects in the area.

> I need to figure out on adapting the XML files to suite KDE's custom
> vCard fields - which i m not really sure how to tackle because as per
> Wikipedia, there are only 8 custom fields, but KAddressBook lets the
> user create his/her own custom fields per contact... which need to be
> taken care of. So what can be done here?

Interesting question. I need to research this a bit, but a here's a
rough outline:
      * for known extensions which map to existing fields, define the
        properties in the profile for KDE/Akonadi (spouse, ...)
      * add two new array fields which hold a) name of the unknown
        extension and b) its value, with a mapping to
        X-KADDRESSBOOK-<name>=<value> in the profile

The second might be a bit tricky. There is a something similar where the
name of a parameter value is composed as
TYPE=X-Synthesis-Ref<something>, but we need that for a property name.

Might involve some coding in libsynthesis. I can do that.

> Also will there be a move to cmake, or how should the Qt/KDE GUI and
> the BlueDevil Plugin (currently using cmake) be integrated (It seems
> to be a really difficult task to move these to autotools) be
> integrated with the current syncevolution?

I would keep them as separate sources with their own build rules. There
are pros and cons for releasing just a single tarball. I think the
disadvantages (having to release an update of everything when just a
frontend used by a subset of the users is modified) outweighs the
advantages (single version number, single release).

The GTK sync-ui is included in the syncevolution source for historic
reasons; I wouldn't do it like that if I started from scratch. It's not
worth changing because it doesn't get modified much these days.


-- 
Bye, Patrick Ohly
--  
Pat...@gm...
http://www.estamos.de/