http://bugzilla.moblin.org/show_bug.cgi?id=7089
--- Comment #22 from pohly <[email protected]> 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. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
