[SyncEvolution] TDEPIM sync questions

[Patrick Ohly]

On Wed, 2016-02-03 at 20:05 +0100, deloptes wrote:
> Hi to all @syncevolution, sorry for bothering you, but I hope one could save
> me some digging by answering my questions.
> I thank you in advance for the patience and support.
> 
> 1.
> I have an item uid: libkcal-1629736449.222 
> which is returned by syncevolution (--print-items) 
> as urlencoded libkcal-1629736449%2e222
> 
> Is this on purpose and why?

Internally, item uids can be arbitrary strings. For use in shell
scripting, the command line tool escapes "unsafe" characters when
printing them and unescapes them when parsing parameters.

So yes, it is intentional. Whether a dot should be considered safe is
debatable.

> 2.
> How are the sources/databases handled - example if I have 3 calendars
> (1default, 1 read only and 1 custom). Imagine I set the custom or the
> default as inactive or active - how would this influence the sync?

I'm not sure I follow. Do you mean you have a sync configuration and
then change the sync mode of one datastore set to "none"? It'll be
ignored when running a sync for that sync configuration.

> 3.
> About the platform support.
> Is this also picked up by the engine automatically ?
> I saw something about KDE in the sync src code as well.
> I would like to implement similar functionality with the tdewallet - it
> sounds like nice feature to have when dealing with passwords, but I need
> some hint here as I was not able to understand from the kde code what
> exactly has to be done, so that syncevo can cope with it.

The platform modules themselves just register themselves when loaded by
hooking into the callbacks provided by the core libraries. For example,
KDEPlatformRegister.cpp hooks into the password handling via the boost
signal returned by GetLoadPasswordSignal().

Then KWalletLoadPasswordSlot() itself decides whether it is active.
UseKWallet() has some comments about the logic for that.

Basically that is what you need to replicate.

> example
> 
> info.m_backendRule = "KDE";

That is not related to password handling. It is what a datastore uses to
configure the conversion from the internal data format into the vCard
"dialect" used by the store.

In this example, src/syncevo/configs/datatypes/01vcard-profile.xml has
conditional rules that are only active in the "KDE" case.

> 4.
> My last question is related to the problem I described earlier. When
> compiled as shared I get the backend registered twice. When I compile
> static it shows up once. I do have different descriptions in the registerMe
> function and in the createSource function.
> Should I post those functions here?

That may help.

Have you tried what I suggested, i.e. removing one of your two shared
modules and checking how that affects the result?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.