http://bugzilla.moblin.org/show_bug.cgi?id=7089
--- Comment #29 from pohly <[email protected]> 2010-01-06 01:49:16 PST --- (In reply to comment #28) > (In reply to comment #26) > > (In reply to comment #25) > > > 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. > > > > The D-Bus client doesn't have to implement much logic: > > - get all configs and templates > > - understand enough of syncURL to find the device it was invoked for > > > > It does not talk to bluez directly, nor does it implement any kind of > > matching > > logic. > Sync-ui has to get device name from bluez. See below: > ‣ Jku's N85 (Bluetooth device) > Enter your device manufacturer and model name [ ] > or select from list of templates [Nokia S60 3rd ed. ∨] > Device name is different from model name. A possible solution is to add a new > property 'device name' in GetConfig. then it doesn't need it, I think. My understanding was that we would add everything that is needed by the sync-ui to the templates, exactly to avoid the sync-ui<->bluez dependency. > > Do you expect the GUI to do more than that? Where do you see an overlap in > > functionality? > If user inputs a new finger information for a given device, since we have no > API to transfer this to dbus server, gui has to do matching against 'phone > model number' itself. This logic is also in syncevolution core. "inputs new finger information" - do you mean that the user enters manufacturer and model manually, then asks to create a config without having that device paired? I don't think we need to support such a use-case. If we do, we'll add the necessary D-Bus API to keep the matching inside the server. -- 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
