http://bugzilla.moblin.org/show_bug.cgi?id=7089
--- Comment #29 from pohly <patrick.ohly(a)intel.com> 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.