http://bugzilla.moblin.org/show_bug.cgi?id=7089
--- Comment #20 from Chen Congwu <[email protected]> 2010-01-05 01:57:23 PST --- (In reply to comment #19) > (In reply to comment #18) > > 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 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. > - 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. > 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. 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) 2) A lot of unnecessary dbus calls, a buffer of memory is needed. 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? -- 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
