Zhu, Yongsheng wrote:
At the moment we cannot run a sync with a temporary source
configuration. The .other.ini node must be created somewhere. We could
change this so that the .other.ini state is thrown away for temporary
sources, but do we really have a use case for this?
I just think it because this is one case which might occur in 'setConfig'. From
the perspective of users, I think they don't care about whether the config is
temporary or saved. For most of users, I think saving their configs is a good idea.
I don't think that's the perspective of the end user, maybe perspective
of a client app... The end user will do what the client application
"guides" them to do. I don't think the idea of temporary configs should
even be communicated to the user in most UIs: it's just the technique
used to do what the user wants (when saving the config is not appropriate).
I think this can be just a documentation issue: "defining new sources
temporarily is not supported". At least until we have a use case for
temporary sources...
That reminds me: there are also several configuration changes which
should trigger a slow sync. We don't have any mechanism in place to
force this right now. The check would have to compare the config of the
last sync with the current config to determine whether "relevant"
properties have changed and .other.ini is still intact. "relevant" is a
bit hard to define, though.
Yes, should need some discussion for this. But firstly I think we could open
a bug entry to track this issue.
Ah yes, this is something I've meant to bring up as well :)
http://bugzilla.moblin.org/show_bug.cgi?id=6365
- Jussi
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
