11:28 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=7089
--- Comment #22 from pohly <patrick.ohly(a)intel.com> 2010-01-05 04:28:49 PST ---
(In reply to comment #21)
> > - 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.
Indeed we can't, because we *must* keep configs around when a device un-pairs.
Otherwise we would loose anchors and change tracking information, thus
preventing incremental syncs.
> > - 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.
Agreed.
> > 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.
I think they should. We can add them as properties, like the "score" value.
That should work without API changes, if we are fine with returning
lots of
templates in GetConfigs...
I think that returning a long list in GetConfigs(templates=true) is acceptable.
It won't be that long anyway: let's assume we have 100 phone templates and 10
paired devices that support SyncML. We'd end up with 100*10*80 (length of each
template name) = ~80KB of string data for template names, followed by 1000
GetConfig() calls. The latter might be more of a problem.
> 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.
We should use these signals. That way we can:
* build a list of templates on startup of syncevo-dbus-server
by querying bluez
* update that list each time bluez sends a signal
* implement presence detection for Bluetooth peers
* implement automatic syncing with them
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.
Agreed. We can always optimize this later on.
--
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.