On Feb 11, 2010, at 11:32 , Patrick Ohly wrote:

> On Do, 2010-02-11 at 06:37 +0000, Chen, Congwu wrote:
>> Patrick wrote:
>>> cfgP->initTarget() jumps to NULL and printing the content of cfgP also
>>> shows some garbage. I suspect that the static_cast<TBinfileDSConfig
>>> *>(*pos) is invalid for super datastores. Does that sound plausible?
>>> 
>> I think you are right. Here is the simple patch that works so far:
> 
> Were you really able to run a SyncML client session with a
> <superdatastore> enabled? Because I can't.
> 
> What SyncEvolution did as client was wrong:
> - in XML config: <datastore> "calendar" and "todo",
>  <superdatastore> "calendar+todo"
> - in profile: enable "calendar" and "todo", but not "calendar+todo"
> 
> As a result, the sync session pretty much ignored <superdatastore> and
> tried to run a sync with "calendar" and "todo" as separate sources.
> 
> Lukas, what would be the right configuration?
> - same XML config
> - disable "calendar" and "todo", enable "calendar+todo"
> 
> I tried that, but I only get a segfault elsewhere.

When I implemented <superdatastore> for the server, I tried to implement it 
such that it would not be completely the wrong way to use it for a client as 
well, but it was never completed for the client case (simply because a 
standards compliant SyncML server MUST provide events and tasks as separate 
datastores, and until OVI I've not seen one that didn't).

What's completely missing is a mechanism that would allow *triggering* the sync 
for events+tasks as superdatastore rather than as separate stores. Backend wise 
they remain two separate stores, so the administrative data (the 
profiles/targets) will also remain separate.

For now, when a sync ist started, SelectProfile() will iterate trough all 
targets in the profile and instantiate the needed datastores for every target 
which has the enabled flag set.

What would be needed is

a) a user settings flag that indicates for some datastores that these must NOT 
be run on their own, but within the superdatastore.

b) An enhanced SelectProfile() in binfileimplclient.cpp, which would check that 
flag and figure out which superdatastore to instantiate in addition to the 
normal datastores.

c) Some tweaking of the for-each-datastore-do-something loops that control the 
flow of a client session (especially syncagent.cpp around 1090, where 
engPrepareClientSyncAlert() is called)



Lukas Zeller ([email protected])
- 
Synthesis AG, SyncML Solutions  & Sustainable Software Concepts
[email protected], http://www.synthesis.ch





_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to