9:54 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=7089
--- Comment #21 from jku <jku(a)linux.intel.com> 2010-01-05 02:54:13 PST ---
> Let's explore the control flow without API changes first:
Patricks list seems pretty good to me.
> - 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
Wondering whether this is necessary. Device pairing is the first time
SyncEvolution sees the device, there should not be existing configs for the
device. When user decides to remove pairing, the configs is also removed
during the un-pairing process.
I don't think we can trust on no configs existing. I also don't think the
un-pairing process should remove configs: un-pairing happens in
bluetooth-applet and syncevolution should find about it next time it tries to
do something -- it could check for pairing status in GetConfigs and either
remove the config if peer is not paired or just not return it to client.
> - 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
Do we need to display any templates that does not match via SyncURL? I don't
think so.
I disagree. The configuration list should be just as it would be if user opened
it herself. The only difference, if possible, should be that the correct peer
is opened already. Anything else would be inconsistent.
> 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.
This is actually close to my original idea: at this point the UI could do the
actual selection with e.g. a "phone model name" filter if the templates include
that sort of searchable meta data.
Something like this in the configuration view:
‣ Jku's N85 (Bluetooth device)
Enter your device manufacturer and model name [ ]
or select from list of templates [Nokia S60 3rd ed. ∨]
That should work without API changes, if we are fine with returning lots of
templates in GetConfigs...
> Template names for Bluetooth peers must be unique. I suggest
> "OBEX/Bluetooth_<mac address>_<number>" where <number>
enumerates the
> templates created for this peer.
This works well for the pairing process. There is another scenario: user did
not configure the paired device during paring but in a later invocation of
sync-ui. So user will have a list of paired devices that have no
configurations. With this assumption, getConfigs(Templates=true) need to match
against all paired devices (via Bluez query) and cache all these configuration
templates in memory. Later sync-ui need to call getConfig(templateName) for
all returned templates to match against the "SyncURL". The limitations are:
1) It need a session concept for the API (getConfigs followed by getConfig)
As I said, I think the UI needs to handle things the same way every time,
special casing the pairing instant is not sufficient. I didn't think that would
require a session for GetConfigs (and I still don't fully understand that) but
if it does, then so be it.
2) A lot of unnecessary dbus calls, a buffer of memory is needed.
If you refer to the BlueZ calls: The same can be implemented with Bluez
signals: Manager.DefaultAdapterChanged, Adapter.DeviceCreated,
Adapter.DeviceRemoved, Device.PropertyChanged (I have not tested these though)
This way syncevolution dbus client calls would never get latency from bluez
calls.
Another problem is: how do you figure out the case when we need user
input to
influence getConfigs(), which as we discussed earlier is inevitable. Do we
still need to add another dbus api for this? If this is true, why not just add
getTemplates(HashTable configs) as I proposed earlier?
The reason I'd be fine with just (ab)using the current API is that we don't
really know how this will work... It might be worth it to wait for a while, and
see how many templates we end up with and how easy/hard the matching is.
--
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.