http://bugzilla.moblin.org/show_bug.cgi?id=4611
--- Comment #5 from pohly <patrick.ohly(a)intel.com> 2009-11-20 01:42:16 PST ---
(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 virtual
> 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
Contacts". When
that backend gets invoked, how does it know which local database it is supposed
to access?
I suggest to solve this problem by referencing other *source* configurations
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:
[calendar+todo]
type = virtual:text/calendar
evolutionsource = calendar,todo
It's a bit unfortunate that I followed Evolution's example with the
"calendar"
name. Other products use "events", "tasks" for what we call
"calendar" and
"todo" and "calendar" for what we have to call
"calendar+todo" (just a
proposal, other ideas are welcome).
Note that only data sources with compatible data formats can be merged, as far
as I understand it. Even if the Synthesis engine supports it, I don't think we
have use cases which require it, so we can impose this limitation ourselves and
thus keep the data format selection via [calendar+todo] working as usual.
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.
I think these problems don't occur with the approach above.
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.
Agreed. Later we can add additional configuration parameters which control the
advanced use cases.
--
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.