http://bugzilla.moblin.org/show_bug.cgi?id=4611
--- Comment #4 from Chen Congwu <congwu.chen(a)intel.com> 2009-11-20 00:30:47 PST
---
(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 virtual
one".
Now comes this solution:
The configuration of type properties is defined as:
backend1+backend2+...backendN:format1+format2_...formatM (0=<M<=N)
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 single
m_forced property is no longer working.
We will maintain a list of all joined datastores, which typically like:
superdatastore1: backend1, backend2,..backendN
This is used later to generate the "superdatastore" configuration.
I'm not sure whether we really need to write a backend. At least
for the "tasks
+ events" use case, the Synthesis engine already has a solution. We just need
to activate it somehow.
Now comes the specific part, the generation of
"superdatastore" element is
different case by case (The filtering criteria). At this time I will always
generate a "super calendar" datastore for the calender +event case to work.
> which will
> map to (calendar+todo), the format used is vcard2.1 and ical2.0 by default,
Why vcard2.1?
Because this is the situation in non-joined case, I just don't want to change.
--
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.