7:34 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=7089
--- Comment #19 from pohly <patrick.ohly(a)intel.com> 2010-01-05 00:34:53 PST ---
(In reply to comment #18)
(In reply to comment #17)
> (In reply to comment #16)
> > Now that I think about it, it is possible to do either way (keep an up-to-date
> > list or query when needed), but I still don't think bluetooth applet should
do
> > it... This is the quick and easy way I think (querying when client asks for
> > templates):
> >
> > org.Bluez.Manager->DefaultAdapter()
> > org.Bluez.Adapter->ListDevices()
> > for all devices:
> > org.Bluez.Device->GetProperties()
> > # if UUIDs property includes the sync uuid, create this template
>
> This sounds really simple. I agree, we should do this instead of forcing the
> plugin to update the syncevo-dbus-server. I thought it would be harder.
>
> Note that we cannot rely on a UUID. We can only use the MAC address for
> matching at this level.
I think we just use UUID to filter against the paired devices to list only
SyncML capable ones.
What do you mean here by matching against macaddress?
I was wondering what this UUID thing is and how we use it. It wasn't clear to
me from Jussi's text above.
Shall we query against syncevo-dbus-server for templates for all
paired SyncML
devices every time even if user never cares about that device? I think this is
what we can do without api changes.
"user cares about that device" = "some checkmark in the bluetooth
panel"? I
agree, without API changes we cannot convey that information to
syncevo-dbus-server and thus have to show all SyncML-capable devices when going
via sync-UI/syncevo-dbus-server.
A better solutions looks like:
getConfigs (true) --Got a list of device peers (via Bluez) and a list of
templates for SyncEvolution clients (Scheduleworld, Funambol, ..
SynceEvolution).
getTemplate (HashTable keys) -- Got a list of templates matching against the
specified keys (possible values are: Device Model/Name, Device Manufacture),
return a list of templates sorted by score. Another "select templates" page
would be added in sync-ui. This page is also where bluetooth-panel will lead
user to after the pairing process.
getConfig (true) --Got the contents for the specified template.
Do I understand correctly?
Do we really need a specific getTemplate() call? How would the sync-UI
determine the necessary keys? Do we want it to talk to bluez to determine them?
Let's explore the control flow without API changes first:
- bluetooth panel plugin finds new device with SyncML
- user chooses to invoke SyncEvolution for it
- "sync-ui --show-settings obex+bluetooth://<mac address>"
- sync-ui checks existing configs for one with that syncURL
- if found, make select that config
- if not, ask for templates
- syncevo-dbus-server returns built-in templates for HTTP servers,
plus templates for all paired Bluetooth peers (more than one
template per peer, ranked according to matching criteria)
- sync-ui searches for the syncURL to find templates for the right
device and presents those first
The sync-ui must be fairly flexible with the --show-settings parameter. It
might also support template names, config names and a "fuzzy" syncURL matching
where only the prefix is checked (ignore channel number and HTTP URL
parameters).
We discussed this ranking before. We could go one step further and return *all*
phone templates for each peer, even if they don't match at all. Then the GUI
has all information and can let the user choose freely.
Template names for Bluetooth peers must be unique. I suggest
"OBEX/Bluetooth_<mac address>_<number>" where <number>
enumerates the templates
created for this peer.
--
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.