On Tue, 2009-12-15 at 04:52 +0000, Chen Congwu wrote:
1) Synchronization with phone (or with a SyncML client over
SyncEvolution as the server needs the configuration for the phone before
syncing. More specifically it is typlically a "server alerted sync" using
The configuration for different phones might be different (For example,
some Nokia phones need to configure a calendar+todo superdatastore, the
database uri on the phones maybe also different).
So how will we manage the configuration templates?
Clearly our solution must scale much more than the current built-in
templates and must be extensible at runtime. I suggest that we avoid
adding such client templates to our source code and go entirely for
template files (similar to what was started in MB #7808).
version? i.e. Nokia_S40, Nokia_S60, ...
I suggest we organize our templates around manufacturer, class of device
(S40, S60, ...), and specific model:
This is just for organizing the files in a more user-friendly way. The
directory hierarchy itself has no meaning for our code. The matching
criteria (vendor, class, model) should better be encoded in a more
machine-readable format inside each directory.
config.ini - main config template file
internal.ini - matching criteria, only (?) used by code which
searches for a template
sources/ - sub-directory with source part of template
How to define and the matching criteria is the key problem that we need
to discuss - is that moved into the front-ends?
We also need a general configuration to possibly work with a
client. (Server alerted + server side configuration)
I see that as special cases of the more general problem. For an
SyncEvolution server and client we should have a built-in template
called "syncevolution" with URIs named as normally done in SyncEvolution
(addressbook, calendar, todo, memo).
2) Synchronization with another SyncML client over HTTP
This corresponds to Moblin Bug #7838, we need to generate the server side
configuration for the particular client during first-time sync. The
template is a "client-inited+server side" configuration template. Note for
different SyncML clients the configuration might also be different but this will
not target at this time, so a template workable for a SyncEvolution based SyncML
client is good enough.
The question is how we integrate that into a SyncML server. Should we
introduce a "default" peer config with username/password that is used to
verify a peer and once it is authorized with that, create such a
As you said, such a config can be very simple. We don't even need to
configure per-peer source properties.
3) Synchronization with another SyncML server over HTTP
In additon to the built in sync service providers, at least we need a
configuration template for a SyncEvolution based SyncML server. (Client inited +
client side configuration)
4) Synchronization with another SyncML server over Bluetooth
OpenSync is a possible target (and SyncEvolution as well as some phones also
have built-in SyncML server support). At least a general configuration template
workable with SyncEvolution based server is needed. (Server alerted + client
Let's target SyncEvolution first, but with lower priority.
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.