--- Comment #6 from Chen Congwu <congwu.chen(a)intel.com> 2009-11-20 02:08:16 PST
(In reply to comment #5)
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > The solution of this problem should be independent of the Evolution backends.
> > The general task is: "combine two (or more) real data sources into one
> > one".
> Now comes this solution:
> The configuration of type properties is defined as:
> backend1+backend2+...backendN:format1+format2_...formatM (0=<M<=N)
I assume that with "backend" you mean something like "Evolution
that backend gets invoked, how does it know which local database it is supposed
That's the part I missed.
I suggest to solve this problem by referencing other *source*
instead of *backends*. Then these other source configurations are defined
normally. A sync where a supersource is active is treated like a sync where
each of the involved normal sources is active (database dumps, reporting, ...).
The configuration could look like this:
type = virtual:text/calendar
evolutionsource = calendar,todo
Do you mean add another dummy source folder
reference other sources to be
joined ? This simplifies my problem but adding duplicated configuration(in this
case calendar, todo, and calendar+todo are mostly duplicated). This is not very
nice and may confuse user. For example is it meaningful to fire a sync with a
Nokia phone asking two-way sync for calendar and slow-sync for todo? Mostly
this does not work.
> The information we lost is: the datastore name is the same as
backend name in
> such joined case which I think is OK.
> Another dirty point is the "forced" property in format, the original
> m_forced property is no longer working.
I think these problems don't occur with the approach above.
I agree with you
and actually I already changed my mind during testing.
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.