Hello!
Thanks for the explanation. I'm working on the client side support.
On Do, 2010-02-11 at 11:19 +0000, Lukas Zeller wrote:
> 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.
How about setting a special URI, like <none>? Because of the angle
brackets it cannot conflict with valid URIs.
> 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.
Is that really necessary? If we require that all relevant targets are
enabled, both for the <superdatastore> and its underlying <datastore>s,
then SelectProfile() can simply instantiate them all.
For that to work, TSuperDataStore must be derived from TBinfileImplDS to
avoid segfaults similar to the one seen earlier. Do you agree with
Congwu's approach of changing the base class?
> 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)
I see that
engPrepareClientSyncAlert(TSuperDataStore *aAsSubDatastoreOf)
is already prepared to take a TSuperDataStore pointer. But that pointer
is never set anywhere, is it? I only find one call which passes NULL.
After changing engPrepareClientSyncAlert() to check for a <none> URI
instead of the always-NULL *aAsSubDatastoreOf, I get the first message
out to the server as expected.
After processing the reply, the client becomes unhappy because it cannot
identify the matching DevInfo entry:
Warning: Remote datastore name '<none>' not found in received DevInf.
Warning: No DevInf for remote datastore, running blind sync attempt
This is in TLocalEngineDS::engInitForSyncOps(). How should that be
handled? The code has some comments about possibly being called earlier.
Would that be the case if the superdatastore had been checked first?
--
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.
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
