On Fr, 2011-08-26 at 18:08 +0200, Patrick Ohly wrote: > Chris, I suspect that I gave you wrong guidance about the use use of > deviceName/peerName, or we have to extend the semantic. According to the > D-Bus API docs: > > * deviceName: device template: the device name that the template > is for (copied verbatim from that device) > * templateName: device template: string identifying the class of > devices the templates works for, like "Nokia S40"; meant to be > shown to users; optional, fall back to first entry in > fingerPrint if not set > > Now the syncevo-dbus-server sends deviceName=Nokia, templateName=Nokia > and peerName=Nokia N97 mini. > > I think it should send: > * deviceName: the vendor/model information if available, otherwise > the user-configurable device name (can't be empty, because > traditionally it wasn't describe as optional) > * templateName: the "templateName" from the template, as it used > to (see above) > * peerName: the user-configurable name (optional, old > syncevo-dbus-servers do not provide it) > > The syncevo-dbus-server's use of deviceName needs to be adapted to meet > this revised definition. > > I suspect that the UI picks the first deviceName that it encounters and > ignores the peerName. Jussi, can you confirm that? > > The UI should be adapted to use peerName instead of deviceName, if > peerName is available. That way the user would see his chosen name > instead of the vendor/model name, which will not be unique in the > (unlikely) case that the user has more than one. Not a big deal. > > We might have the inverse situation, too: multiple different devices all > called "My Phone". I think users should (and can) avoid this, so we > should continue to display only the chosen name instead of adding the > vendor/model information - right?
Given that the UI should only display the chosen name, and expects it in "deviceName", perhaps we should keep the traditional D-Bus API semantic unchanged and put the Device ID profile information into the "peerName"? That is a bit backwards (peerName is used for user-configurable strings elsewhere), but has the advantage that no changes will be needed in the D-Bus clients to get the desired behavior. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
