On Di, 2011-08-30 at 12:33 +0200, Chris Kühl wrote:
> On Mon, Aug 29, 2011 at 5:27 PM, Patrick Ohly <[email protected]> wrote:
> > On Mo, 2011-08-29 at 15:12 +0200, Patrick Ohly wrote:
> >> > 1) In the case that we have no PnPInformation info we have...
> >> >
> >> > deviceName = User-modifiable name
> >> > peerName = User-modifiable name
> >>
> >> Better leave the peerName unset. It's semantic will be "we know for sure
> >> that this device is a "<vendor>[ <product>]".
> >
> > You decided to not implement it like this, did you?
> 
> That was an oversight. Attached, you'll find updated patch.

Thanks, merged. When writing the API docs for it I got unhappy about the
overloading of peerName that I had suggested earlier and ended up
renaming the property. See attached patch (from master).

> I agree that there is a need to be able for the client code to know
> that they have reliable info or not. Setting peerName to empty is a
> good way to do that.

Or better, don't even send it.

> I've also attached a n updated patch for the script. Just adds a
> header with copyright and license info.

Also merged.

-- 
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.

>From 9f4a9a801755829a237caa1f6cb1f096e5757e88 Mon Sep 17 00:00:00 2001
From: Patrick Ohly <[email protected]>
Date: Tue, 6 Sep 2011 12:53:42 +0200
Subject: [PATCH] D-Bus server: send hardware info in new "hardwareName" read-only property

The previously suggested (and implemented) approach of reusing the
peerName property to convey hardware information didn't pass the smell
test (too complex to explain that the same property has different
meanings depending on the context).

So now a new "hardwareName" property is used instead. Also renamed
the TemplateDescription member accordingly, updated the API docs
and implemented the "hardwareName only set if known" part of it.
---
 src/dbus/interfaces/syncevo-server-full.xml |   16 +++++++++++++---
 src/dbus/server/read-operations.cpp         |    4 +++-
 src/dbus/server/session.cpp                 |    1 +
 src/syncevo/SyncConfig.h                    |    6 +++---
 4 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/src/dbus/interfaces/syncevo-server-full.xml b/src/dbus/interfaces/syncevo-server-full.xml
index 8a58f7f..d0b1eb6 100644
--- a/src/dbus/interfaces/syncevo-server-full.xml
+++ b/src/dbus/interfaces/syncevo-server-full.xml
@@ -251,8 +251,10 @@
         and values matching those in the SyncEvolution server 
         configuration files.</doc:para>
 
-        <doc:para>In addition, some special keys for read-only
-        values are added:
+        <doc:para>In addition, some special keys for read-only values
+        are added. These entries may be set when reading a config or
+        template and can be sent when writing it, but will not
+        actually be stored.
         <doc:list>
           <doc:item>
             <doc:term>configName</doc:term>
@@ -279,7 +281,7 @@
           <doc:item>
             <doc:term>deviceName</doc:term>
             <doc:definition>device template: the device name that the template is for
-            (copied verbatim from that device)</doc:definition>
+            (copied verbatim from that device, typically chosen by the user of the device)</doc:definition>
           </doc:item>
           <doc:item>
             <doc:term>templateName</doc:term>
@@ -289,6 +291,14 @@
             fingerPrint if not set</doc:definition>
           </doc:item>
           <doc:item>
+            <doc:term>hardwareName</doc:term>
+            <doc:definition>device template: "<vendor>[ <model>]" string extracted
+            from a device database, unset if neither vendor nor model are known. The
+            deviceName above is probably a better way to present the device to the user,
+            because if a user has multiple identical devices, he hopefully chose
+            unique names for them.</doc:definition>
+          </doc:item>
+          <doc:item>
             <doc:term>fingerPrint</doc:term>
             <doc:definition>device template: comma separated list of devices which
             work with this template, typically in "vendor model"
diff --git a/src/dbus/server/read-operations.cpp b/src/dbus/server/read-operations.cpp
index 31d9905..ccada95 100644
--- a/src/dbus/server/read-operations.cpp
+++ b/src/dbus/server/read-operations.cpp
@@ -122,7 +122,9 @@ void ReadOperations::getConfig(bool getTemplate,
             localConfigs.insert(pair<string, string>("deviceName", peerTemplate->m_deviceName));
             // This is the reliable device info obtained from the bluetooth
             // device id profile (DIP) or emtpy if DIP not supported.
-            localConfigs.insert(pair<string, string>("peerName", peerTemplate->m_peerName));
+            if (!peerTemplate->m_hardwareName.empty()) {
+                localConfigs.insert(pair<string, string>("hardwareName", peerTemplate->m_hardwareName));
+            }
             // This is the fingerprint of the template
             localConfigs.insert(pair<string, string>("fingerPrint", peerTemplate->m_matchedModel));
             // This is the template name presented to UI (or device class)
diff --git a/src/dbus/server/session.cpp b/src/dbus/server/session.cpp
index 40a7c39..4c4d4df 100644
--- a/src/dbus/server/session.cpp
+++ b/src/dbus/server/session.cpp
@@ -91,6 +91,7 @@ static void setSyncFilters(const ReadOperations::Config_t &config,FilterConfigNo
                     "description",
                     "score",
                     "deviceName",
+                    "hardwareName",
                     "templateName",
                     "fingerprint"
                 };
diff --git a/src/syncevo/SyncConfig.h b/src/syncevo/SyncConfig.h
index a07b8d1..f5103d9 100644
--- a/src/syncevo/SyncConfig.h
+++ b/src/syncevo/SyncConfig.h
@@ -1036,7 +1036,7 @@ class SyncConfig {
         // name, or product name (vendor + model). This depends on
         // whether the device supports the Bluetooth Device ID profile
         // and, if so, whether we have the model in the lookup table.
-        std::string m_peerName;
+        std::string m_hardwareName;
 
         //a unique identity of the device that the template is for, used by caller
         std::string m_deviceId;
@@ -1056,13 +1056,13 @@ class SyncConfig {
         std::string m_templateName;
 
         TemplateDescription (const std::string &templateId, const std::string &description,
-                             const int rank, const std::string &peerName, const std::string &deviceId,
+                             const int rank, const std::string &hardwareName, const std::string &deviceId,
                              const std::string &fingerprint, const std::string &path,
                              const std::string &model, const std::string &templateName)
             :   m_templateId (templateId),
                 m_description (description),
                 m_rank (rank),
-                m_peerName (peerName),
+                m_hardwareName (hardwareName),
                 m_deviceId (deviceId),
                 m_deviceName (fingerprint),
                 m_path (path),
-- 
1.7.2.5

_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to