On Tue, 2009-12-15 at 04:52 +0000, Chen Congwu wrote:
> 1) Synchronization with phone (or with a SyncML client over Bluetooth)
> SyncEvolution as the server needs the configuration for the phone before
> syncing. More specifically it is typlically a "server alerted sync" using
> bluetooth transport.
> 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).
> Per Manufacture+OS
> version? i.e. Nokia_S40, Nokia_S60, ...
I suggest we organize our templates around manufacturer, class of device
(S40, S60, ...), and specific model:
Nokia/
default/
S40/
default/
7120c/
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.
Nokia/default/
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 SyncEvolution
> based
> 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
peer-specific config?
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)
Agreed.
> 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
> side configuration).
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.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
