http://bugzilla.moblin.org/show_bug.cgi?id=7089
yongsheng zhu <yongsheng.zhu(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |yongsheng.zhu(a)intel.com
--- Comment #25 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-01-05 18:01:33
PST ---
(In reply to comment #23)
(In reply to comment #22)
> We should use these signals. That way we can:
> * build a list of templates on startup of syncevo-dbus-server
> by querying bluez
Before getting templates, I assume sync-ui gets the list
of existing configs to
check whether a given config could match a given device, right?
For this step, we calculate 'score' and save 'phone model name' in filters
for
each template, so we have to maintain a big vector to save this configs in
GetConfigs(True), and then return them when dbus clients call getConfig(True).
That's the concern of Congwu's 1:
1) Large number of getConfig() dbus call, as Patrick pointed out. All templates
need be held in memory throughout the whole dbus server life cycle.
> * update that list each time bluez sends a signal
> * implement presence detection for Bluetooth peers
> * implement automatic syncing with them
Just for the record: The first two are doable with the signals I mentioned (or
similar, I'm not 100% sure) but the last two require syncevolution initiated
action.
Yes, reasonable.
It seems to me that both dbus server and dbus client have to be aware of
bluetooth service and handle many logics. I think maybe many logics and
processing are overlapped.
--
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.