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.