http://bugzilla.moblin.org/show_bug.cgi?id=7089
yongsheng zhu <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #25 from yongsheng zhu <[email protected]> 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. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
