Open Source Synthesis SyncML Engine: PIM data synchronization and more ()

headers zhou lei | 1 Apr 2012 04:16

_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@...
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Hi Zhoulei,

On Apr 1, 2012, at 4:16 , zhou lei wrote:

> I just try it as what to told me to do, and the client works. Thank you very much.

Glad to hear it works now!

> For property "TEL" in the vcard, it just has too many enum values, how could i set the "TEL" value with its
enum flags. If only set it by the setstringvaluebyname, It may use the default one, but i want to set it myself.

The TEL_FLAGS is just an integer field used as a bitmap to create the TYPE parameter. So bit 0 set will add
HOME, bit 1 WORK etc.

So to make a TEL;TYPE=WORK:123456789 telephone number (all three the same in this sample), you would
something like:

     // - strings in an array
     sInt32 telFieldID = [aItemKey valueIDByName:"TEL"];
     sInt32 telFlagsID = [aItemKey valueIDByName:"TEL_FLAGS"];
     for (int i=0; i<3; i++) {
       [aItemKey setStringValueByID:telFieldID arrayIndex:i toValue: <at> "123456789"];
       [aItemKey setIntValueByID:telFieldID arrayIndex:i toValue:(1<<1)]; // set bit 1 to make it a WORK number
     }

The other fields, "TEL_LABEL" and "TEL_ID" are to support the custom label feature of the iOS address book,
and also to expose the iOS ID of the array elements. If you have your own address book database, you probably
don't need these and you could remove these extra fields from the XML config as well.

Please also have a look at the conversion modes and options around page 81 of the
"doc/SySync_config_reference.pdf". Also, on page 86 there is a much simpler example of how to map
telephone numbers to a few fixed fields (instead of arrays). Depending on your address book, that might
make more sense to implement, rather than using the complex mapping needed for the iOS address book which
can hold a variable number of TELs for each contact and has custom labels and IDs.

Best Regards,

Lukas Zeller

_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@...
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Hi Zhoulei,

On Apr 23, 2012, at 4:06 , zhou lei wrote:

> I am working on Funambol server for a week, and it just could not connect to the oracle db. And I am not good at
java, and using maven an ant is not that easy. 
> And I was think about that, if using the libsynthesis it could be easy, dosen't it?

It depends on how complicated your database schema is. If you can map the fields from the <fieldlist> more or
less 1:1 to fields in your database, this is indeed easy to do with libsynthesis. You can do the mapping in
the XML config, with no need to code anything in Java.
You'd need to install the ODBC driver for Oracle though, as libsynthesis uses ODBC to connect to databases.

> Is there a useful demo server for linux ?

Not based on libsynthesis at this time.

Synthesis still provides a full server as a commercial product, and there are free demo and eval packages of
a complete server you can download from their site. The database connection part of these is exactly the
same as in opensource libsynthesis, so to check if integration with your Oracle DB works you could use the
Synthesis EVAL version.
After that, it'll be a make or buy decision wether you want to license the server from them, or build your own
based on libsynthesis. The database connection will be the same.

To make a server out of libsynthesis, what needs to be done outside libsynthesis is the connection to the
HTTP transport, and session handling (SyncML session objects must be kept around between HTTP requests
until the entire session completes or is aborted).

The opensource SyncEvolution project has done this, however SyncEvolution has quite some complexity of
its own so I don't know how easy it would be to use the HTTP transport code from SyncEvolution.

Best Regards,

Lukas Zeller, plan44.ch
luz@... - www.plan44.ch

On Mon, 2012-04-23 at 22:23 +0200, Lukas Zeller wrote:
> To make a server out of libsynthesis, what needs to be done outside
> libsynthesis is the connection to the HTTP transport, and session
> handling (SyncML session objects must be kept around between HTTP
> requests until the entire session completes or is aborted).
> 
> The opensource SyncEvolution project has done this, however
> SyncEvolution has quite some complexity of its own so I don't know how
> easy it would be to use the HTTP transport code from SyncEvolution.

It would be pretty hard. The HTTP server in SyncEvolution is written in
Python using the Twisted framework and depends on the D-Bus API provided
by the SyncEvolution core, so one also inherits all the rest of
SyncEvolution (own configuration system, backends, etc.).

For writing one's own server, the Synthesis SDK and server will be
easier.

--

-- 
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.

Hello!

I am trying to solve one issue in SyncEvolution: when trying to find
pairs, it needs to know on a per-datastore basis whether both remote and
local storage have truly unique UID/RECURRENCE-ID that can be relied
upon (iCalendar 2.0 semantic).

So far, I am using a compare script for that, but it has to make
assumptions about the peer. To overcome that I added code that allows
clients to add SyncCap entries to the CTCap (similar to the "can restart
flag"). This information is stored at the receiving end in the
TSyncDataStore base class by the TRemoteDataStore while parsing the
SyncCap (again, very similar to "fCanRestart").

But now my problem is: how can the compare script access that
information?

It runs inside the "datatype context". Does that mean that all
datastores sharing the same type also share the same context and that
the <initscript> for the type is only invoked once?

The script functions in multifielditemtype.cpp (like SYNCOP()) looked
promising. It's possible to get a pointer to some kind of datastore:

TSyncDataStore *related = static_cast<TMultiFieldItemType *>(aFuncContextP->getCallerContext())->getRelatedDatastore();

But in practice that pointer is always NULL. I wasn't sure anyway
whether I would get the pointer to the local or remote datastore.

Any hints?

--

-- 
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.

Hello Patrick,

On Apr 25, 2012, at 15:11 , Patrick Ohly wrote:

> I am trying to solve one issue in SyncEvolution: when trying to find
> pairs, it needs to know on a per-datastore basis whether both remote and
> local storage have truly unique UID/RECURRENCE-ID that can be relied
> upon (iCalendar 2.0 semantic).
> 
> So far, I am using a compare script for that, but it has to make
> assumptions about the peer. To overcome that I added code that allows
> clients to add SyncCap entries to the CTCap (similar to the "can restart
> flag"). This information is stored at the receiving end in the
> TSyncDataStore base class by the TRemoteDataStore while parsing the
> SyncCap (again, very similar to "fCanRestart").

The problem is that CTCap is not necessarily tied to a datastore. It is since SyncML 1.2, but wasn't before.
That's also the reason why getRelatedDatastore() can be NULL. It is also NULL when using a type from a
script with the MAKETEXTWITHPROFILE et. al. functions.

> But now my problem is: how can the compare script access that
> information?
> 
> It runs inside the "datatype context". Does that mean that all
> datastores sharing the same type also share the same context and that
> the <initscript> for the type is only invoked once?

<insert English word for "Jein">. The datatype context indeed exists only once per type, so the script
variables exist only once.
However, the init script might be called more than once if multiple datastores are using the same type. The
TScriptContext object will be the same, but script functions that use fDsP (see below) can return
different information. So using these in the initscript usually makes no sense.

> The script functions in multifielditemtype.cpp (like SYNCOP()) looked
> promising. It's possible to get a pointer to some kind of datastore:
> 
> TSyncDataStore *related = static_cast<TMultiFieldItemType *>(aFuncContextP->getCallerContext())->getRelatedDatastore();

For getting the local datastore related to a particular script invocation, there is

  TLocalEngineDS *related = static_cast<TMultiFieldItemType *>(aFuncContextP->getCallerContext())->fDsP;

fDsP is one of several variables I'd call "current type usage context", fCurrentSyncOp which feeds the
SYNCOP() script function is another one of them (See multifielitemtype.h Line 202 ff).

> But in practice that pointer is always NULL. I wasn't sure anyway
> whether I would get the pointer to the local or remote datastore.

from fDsP you'd get the pointer to the local datastore (TLocalEngineDS *).

So to reach the remote datastore from a given TMultiFieldItem (which you certainly have at
comparescript), I'd rather use

  yourMultiFieldItem->getRemoteItemType->getRelatedDatastore()

to get to the datastore that has defined that item's remote type. As said, in SyncML 1.1/1.0 cases you'd get
NULL back because the devInf does not associate types with datastores at all. But I'd assume your
extension does not have to work below 1.2, so that'll be no problem.

Best Regards,

Lukas

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30

2	March 2013
4	December 2012
1	October 2012
1	September 2012
1	August 2012
14	June 2012
19	May 2012
7	April 2012
17	March 2012
2	February 2012
1	December 2011
12	October 2011
34	September 2011
18	August 2011
13	July 2011
19	June 2011
3	May 2011
2	April 2011
3	February 2011
5	January 2011
23	December 2010
5	November 2010
1	October 2010
10	September 2010
3	August 2010
4	June 2010
22	May 2010
8	April 2010
49	March 2010
50	February 2010
22	January 2010
27	December 2009
34	November 2009
62	October 2009
80	September 2009
29	August 2009
43	July 2009
72	June 2009
10	May 2009

The sync works now. But some other problems about the set value.

Re: The sync works now. But some other problems about the set value.

Sync server with oracle database

Re: Sync server with oracle database

Re: Sync server with oracle database

scripts + datastore

Re: scripts + datastore