1:02 a.m.
Hi,
I've been working on retrieving the immutable vendor and product id
provided by the Bluetooth Device ID profile (DIP). See my
bluetooth-device-id branch[1] for what's been pushed so far.
Being that we now have a means of getting reliable device information
it seems to me that in the cases where this information was
attainable, a matching score is no longer needed. If the fingerprint
matches the product name from the look-up table exactly (and it will
because we've created the lookup table and the template fingerprints)
we suggest just that one template instead of several. If we didn't get
this product name from the look-up table then everything should behave
as normal because we can't trust the user-modifiable device name
string.
Does this sound reasonable or are there other reasons you'd want more
than one template to choose from even when you're sure which device
you're dealing with?
Cheers,
Chris
[1]
https://meego.gitorious.org/meego-middleware/syncevolution/commits/blueto...
1:58 a.m.
On Mi, 2011-08-03 at 17:02 +0200, Chris Kühl wrote:
Hi,
I've been working on retrieving the immutable vendor and product id
provided by the Bluetooth Device ID profile (DIP). See my
bluetooth-device-id branch[1] for what's been pushed so far.
Being that we now have a means of getting reliable device information
it seems to me that in the cases where this information was
attainable, a matching score is no longer needed. If the fingerprint
matches the product name from the look-up table exactly (and it will
because we've created the lookup table and the template fingerprints)
we suggest just that one template instead of several. If we didn't get
this product name from the look-up table then everything should behave
as normal because we can't trust the user-modifiable device name
string.
Does this sound reasonable or are there other reasons you'd want more
than one template to choose from even when you're sure which device
you're dealing with?
What about a Sony Ericcson phone which unknown product ID? We have two
templates for vendor=Sony Ericsson.
I agree that if the vendor matches exactly one template, preferring that
template makes sense. I can imagine corner cases where it is not the
right one (unknown Sony Ericsson phone which behaves like a Nokia), but
that should be unlikely. So we should take advantage of the more
reliable information to propose only one template.
--
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.
12:29 a.m.
On Wed, Aug 3, 2011 at 5:58 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mi, 2011-08-03 at 17:02 +0200, Chris Kühl wrote:
> Hi,
>
> I've been working on retrieving the immutable vendor and product id
> provided by the Bluetooth Device ID profile (DIP). See my
> bluetooth-device-id branch[1] for what's been pushed so far.
>
> Being that we now have a means of getting reliable device information
> it seems to me that in the cases where this information was
> attainable, a matching score is no longer needed. If the fingerprint
> matches the product name from the look-up table exactly (and it will
> because we've created the lookup table and the template fingerprints)
> we suggest just that one template instead of several. If we didn't get
> this product name from the look-up table then everything should behave
> as normal because we can't trust the user-modifiable device name
> string.
>
> Does this sound reasonable or are there other reasons you'd want more
> than one template to choose from even when you're sure which device
> you're dealing with?
What about a Sony Ericcson phone which unknown product ID? We have two
templates for vendor=Sony Ericsson.
In this case it would work just as before. If the device supports the
Device ID profile but it's not in our look-up table of known devices
then we don't use it. We need the look-up table to get the product
string.
There are 2 things that have to happen for the matching score to be unnecessary.
1) The device needs to be in the look-up table.
2) The template needs to have a fingerprint that matches the product
string from the look-up table exactly. If we or the user has added it
here then this should be the template to use.
If both are not fulfilled then we do as we've been doing.
I agree that if the vendor matches exactly one template, preferring
that
template makes sense. I can imagine corner cases where it is not the
right one (unknown Sony Ericsson phone which behaves like a Nokia), but
that should be unlikely. So we should take advantage of the more
reliable information to propose only one template.
If there is a Sony Ericsson that acts as a Nokia then the product id
should be in the Nokia template, right? Or we can just copy that
template and rename it which would probably more clear for the user.
With this I'm assuming that fingerprints are only added to templates
once the template is confirmed to be appropriate for that device.
Cheers,
Chris.
1:26 a.m.
On Do, 2011-08-04 at 16:29 +0200, Chris Kühl wrote:
On Wed, Aug 3, 2011 at 5:58 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Mi, 2011-08-03 at 17:02 +0200, Chris Kühl wrote:
>> Hi,
>>
>> I've been working on retrieving the immutable vendor and product id
>> provided by the Bluetooth Device ID profile (DIP). See my
>> bluetooth-device-id branch[1] for what's been pushed so far.
>>
>> Being that we now have a means of getting reliable device information
>> it seems to me that in the cases where this information was
>> attainable, a matching score is no longer needed. If the fingerprint
>> matches the product name from the look-up table exactly (and it will
>> because we've created the lookup table and the template fingerprints)
>> we suggest just that one template instead of several. If we didn't get
>> this product name from the look-up table then everything should behave
>> as normal because we can't trust the user-modifiable device name
>> string.
>>
>> Does this sound reasonable or are there other reasons you'd want more
>> than one template to choose from even when you're sure which device
>> you're dealing with?
>
> What about a Sony Ericcson phone which unknown product ID? We have two
> templates for vendor=Sony Ericsson.
>
In this case it would work just as before. If the device supports the
Device ID profile but it's not in our look-up table of known devices
then we don't use it. We need the look-up table to get the product
string.
I was working based on the assumption that our look-up table of devices
and the corresponding entries in the templates will be very small.
Where would we get a full list of product IDs for all Nokia phones ever
published, for example? And even if we could get such a list, do we add
all of those names to the Nokia template, without confirmation that it
really works? As you said, we shouldn't.
So the more realistic outcome is that we have to make decisions based on
just the vendor name.
There are 2 things that have to happen for the matching score to be
unnecessary.
1) The device needs to be in the look-up table.
2) The template needs to have a fingerprint that matches the product
string from the look-up table exactly. If we or the user has added it
here then this should be the template to use.
If both are not fulfilled then we do as we've been doing.
Okay. In that case the code needs to use the vendor name from the Device
ID profile instead of the user-assigned device name in the traditional
fuzzy search.
--
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.
1:42 a.m.
On Thu, Aug 4, 2011 at 5:26 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Do, 2011-08-04 at 16:29 +0200, Chris Kühl wrote:
> On Wed, Aug 3, 2011 at 5:58 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > On Mi, 2011-08-03 at 17:02 +0200, Chris Kühl wrote:
> >> Hi,
> >>
> >> I've been working on retrieving the immutable vendor and product id
> >> provided by the Bluetooth Device ID profile (DIP). See my
> >> bluetooth-device-id branch[1] for what's been pushed so far.
> >>
> >> Being that we now have a means of getting reliable device information
> >> it seems to me that in the cases where this information was
> >> attainable, a matching score is no longer needed. If the fingerprint
> >> matches the product name from the look-up table exactly (and it will
> >> because we've created the lookup table and the template fingerprints)
> >> we suggest just that one template instead of several. If we didn't get
> >> this product name from the look-up table then everything should behave
> >> as normal because we can't trust the user-modifiable device name
> >> string.
> >>
> >> Does this sound reasonable or are there other reasons you'd want more
> >> than one template to choose from even when you're sure which device
> >> you're dealing with?
> >
> > What about a Sony Ericcson phone which unknown product ID? We have two
> > templates for vendor=Sony Ericsson.
> >
>
> In this case it would work just as before. If the device supports the
> Device ID profile but it's not in our look-up table of known devices
> then we don't use it. We need the look-up table to get the product
> string.
I was working based on the assumption that our look-up table of devices
and the corresponding entries in the templates will be very small.
Yes this is small currently, but should grow. And I plan on trying to
crowd source this information once the Desktop Summit is over. Of
course as you state below this doesn't mean we know which template
this should be assigned to.
Where would we get a full list of product IDs for all Nokia phones
ever
published, for example? And even if we could get such a list, do we add
all of those names to the Nokia template, without confirmation that it
really works? As you said, we shouldn't.
So the more realistic outcome is that we have to make decisions based on
just the vendor name.
Right. This is available without support for the Device Id profile, by
using a portion of the mac address.
> There are 2 things that have to happen for the matching score to
be unnecessary.
>
> 1) The device needs to be in the look-up table.
> 2) The template needs to have a fingerprint that matches the product
> string from the look-up table exactly. If we or the user has added it
> here then this should be the template to use.
>
> If both are not fulfilled then we do as we've been doing.
Okay. In that case the code needs to use the vendor name from the Device
ID profile instead of the user-assigned device name in the traditional
fuzzy search.
Ok. Some of the names in the vendor list obtained from the Bluetooth
SIG would not match our fingerprints. For example, Sony Ericsson is
"Ericsson Technology Licensing." SE also has another entry that reads
"Sony Ericsson Mobile Communications." We either need to rename them
to match in the list or in the config templates. I say we change it in
the list.
Cheers,
Chris
5:50 a.m.
On Do, 2011-08-04 at 17:42 +0200, Chris Kühl wrote:
On Thu, Aug 4, 2011 at 5:26 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> I was working based on the assumption that our look-up table of devices
> and the corresponding entries in the templates will be very small.
>
Yes this is small currently, but should grow. And I plan on trying to
crowd source this information once the Desktop Summit is over. Of
course as you state below this doesn't mean we know which template
this should be assigned to.
I was trying to grow the list of know and tested devices with the
http://syncevolution.org/wiki/phone-compatibility-template template page
and the resulting Wiki query for "phone":
http://syncevolution.org/taxonomy/term/phone
The result has been somewhat mixed. Directly after the initial
SyncEvolution 1.0 release, some entries were added, but that stopped
soon after.
It definitely would be good to advertise that SyncEvolution really works
with phones and how to report success/failure.
> Where would we get a full list of product IDs for all Nokia
phones ever
> published, for example? And even if we could get such a list, do we add
> all of those names to the Nokia template, without confirmation that it
> really works? As you said, we shouldn't.
>
> So the more realistic outcome is that we have to make decisions based on
> just the vendor name.
>
Right. This is available without support for the Device Id profile, by
using a portion of the mac address.
Do we have and/or need code for that kind of lookup? Please correct me
if I'm mistaken, but isn't Device ID profile support wide-spread enough
that we can rely on it exclusively find the vendor name?
>> There are 2 things that have to happen for the matching
score to be unnecessary.
>>
>> 1) The device needs to be in the look-up table.
>> 2) The template needs to have a fingerprint that matches the product
>> string from the look-up table exactly. If we or the user has added it
>> here then this should be the template to use.
>>
>> If both are not fulfilled then we do as we've been doing.
>
> Okay. In that case the code needs to use the vendor name from the Device
> ID profile instead of the user-assigned device name in the traditional
> fuzzy search.
>
Ok. Some of the names in the vendor list obtained from the Bluetooth
SIG would not match our fingerprints. For example, Sony Ericsson is
"Ericsson Technology Licensing." SE also has another entry that reads
"Sony Ericsson Mobile Communications." We either need to rename them
to match in the list or in the config templates. I say we change it in
the list.
I agree.
--
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.
11:05 p.m.
On Thu, Aug 4, 2011 at 9:50 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Do, 2011-08-04 at 17:42 +0200, Chris Kühl wrote:
> On Thu, Aug 4, 2011 at 5:26 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > I was working based on the assumption that our look-up table of devices
> > and the corresponding entries in the templates will be very small.
> >
>
> Yes this is small currently, but should grow. And I plan on trying to
> crowd source this information once the Desktop Summit is over. Of
> course as you state below this doesn't mean we know which template
> this should be assigned to.
I was trying to grow the list of know and tested devices with the
http://syncevolution.org/wiki/phone-compatibility-template template page
and the resulting Wiki query for "phone":
http://syncevolution.org/taxonomy/term/phone
The result has been somewhat mixed. Directly after the initial
SyncEvolution 1.0 release, some entries were added, but that stopped
soon after.
It definitely would be good to advertise that SyncEvolution really works
with phones and how to report success/failure.
I'll put together a blog post and script or one-liner to make it easy
for people to submit new device id entries.
> > Where would we get a full list of product IDs for all Nokia phones ever
> > published, for example? And even if we could get such a list, do we add
> > all of those names to the Nokia template, without confirmation that it
> > really works? As you said, we shouldn't.
> >
> > So the more realistic outcome is that we have to make decisions based on
> > just the vendor name.
> >
>
> Right. This is available without support for the Device Id profile, by
> using a portion of the mac address.
Do we have and/or need code for that kind of lookup? Please correct me
if I'm mistaken, but isn't Device ID profile support wide-spread enough
that we can rely on it exclusively find the vendor name?
This information is available in the hwdata package on most distros.
More specifically it's in the oui.txt file. Not sure if there are
parsing routines for that file. As you mention though, for most of the
phones that we'll be syncing via bluetooth, the PnPInformation from
the Device ID Profile will be available.
> >> There are 2 things that have to happen for the matching
score to be unnecessary.
> >>
> >> 1) The device needs to be in the look-up table.
> >> 2) The template needs to have a fingerprint that matches the product
> >> string from the look-up table exactly. If we or the user has added it
> >> here then this should be the template to use.
> >>
> >> If both are not fulfilled then we do as we've been doing.
> >
> > Okay. In that case the code needs to use the vendor name from the Device
> > ID profile instead of the user-assigned device name in the traditional
> > fuzzy search.
> >
>
> Ok. Some of the names in the vendor list obtained from the Bluetooth
> SIG would not match our fingerprints. For example, Sony Ericsson is
> "Ericsson Technology Licensing." SE also has another entry that reads
> "Sony Ericsson Mobile Communications." We either need to rename them
> to match in the list or in the config templates. I say we change it in
> the list.
I agree.
I've done this for Nokia and Sony Ericsson.
Also, I think I'm pretty much done Bluetooth work. I've commit my
changes to the bluetooth-device-id branch[1] and updated the bug[2].
Cheers,
Chris
[1]:
https://meego.gitorious.org/meego-middleware/syncevolution/commits/blueto...
[2]: https://bugs.meego.com/show_bug.cgi?id=736#c3
--
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.
11:51 p.m.
On Mon, Aug 15, 2011 at 3:05 PM, Chris Kühl <blixtra(a)gmail.com> wrote:
On Thu, Aug 4, 2011 at 9:50 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Do, 2011-08-04 at 17:42 +0200, Chris Kühl wrote:
>> On Thu, Aug 4, 2011 at 5:26 PM, Patrick Ohly <patrick.ohly(a)intel.com>
wrote:
>> > I was working based on the assumption that our look-up table of devices
>> > and the corresponding entries in the templates will be very small.
>> >
>>
>> Yes this is small currently, but should grow. And I plan on trying to
>> crowd source this information once the Desktop Summit is over. Of
>> course as you state below this doesn't mean we know which template
>> this should be assigned to.
>
> I was trying to grow the list of know and tested devices with the
> http://syncevolution.org/wiki/phone-compatibility-template template page
> and the resulting Wiki query for "phone":
> http://syncevolution.org/taxonomy/term/phone
>
> The result has been somewhat mixed. Directly after the initial
> SyncEvolution 1.0 release, some entries were added, but that stopped
> soon after.
>
> It definitely would be good to advertise that SyncEvolution really works
> with phones and how to report success/failure.
I'll put together a blog post and script or one-liner to make it easy
for people to submit new device id entries.
I've created a script so that users can easily get and then submit the
information that we need. It's not perfect but it seems to work
alright. Here's the gitorious link:
https://gitorious.org/bluetooth-device-id-inspector
I've also got a blog post ready to go once I get some feedback on the script.
Cheers,
Chris
11:25 p.m.
On Di, 2011-08-16 at 15:51 +0200, Chris Kühl wrote:
I've created a script so that users can easily get and then
submit the
information that we need. It's not perfect but it seems to work
alright. Here's the gitorious link:
https://gitorious.org/bluetooth-device-id-inspector
I've also got a blog post ready to go once I get some feedback on the script.
When I ran it, I got the following question:
What company makes this phone?
There was no other output that would have allowed me to identify which
of my paired Bluetooth devices the script was talking about. I guess it
should have printed the user-assigned device name first, plus perhaps
the MAC address.
In the script you volunteer to collect the feedback. So you intend to
stay around? Great, welcome :-)
Should we encourage users to also try syncing with their device, so that
we not only get "this device exists" but also "it works with this
config"?
It shouldn't be required because the hurdle is a lot higher (must
install SyncEvolution first, may change data on phone).
--
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.
11:41 p.m.
On Thu, Aug 18, 2011 at 3:25 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Di, 2011-08-16 at 15:51 +0200, Chris Kühl wrote:
> I've created a script so that users can easily get and then submit the
> information that we need. It's not perfect but it seems to work
> alright. Here's the gitorious link:
> https://gitorious.org/bluetooth-device-id-inspector
>
> I've also got a blog post ready to go once I get some feedback on the script.
When I ran it, I got the following question:
What company makes this phone?
There was no other output that would have allowed me to identify which
of my paired Bluetooth devices the script was talking about. I guess it
should have printed the user-assigned device name first, plus perhaps
the MAC address.
True. I think I had in mind that only one phone would be queried. I
then wrote the code to walk over all devices, though. I'll change it
to display the device name and maybe the MAC address as well with some
text to explain.
In the script you volunteer to collect the feedback. So you intend
to
stay around? Great, welcome :-)
Well, I'd like to see as many devices supported as possible. So, yeah,
I'm willing to take the time to insert the info in the table, etc.
Should we encourage users to also try syncing with their device, so
that
we not only get "this device exists" but also "it works with this
config"?
It shouldn't be required because the hurdle is a lot higher (must
install SyncEvolution first, may change data on phone).
Sure, I could politely point them to the wiki tutorials that Dave worked on.
Cheers,
Chris
12:03 a.m.
On Mo, 2011-08-15 at 15:05 +0200, Chris Kühl wrote:
Also, I think I'm pretty much done Bluetooth work. I've
commit my
changes to the bluetooth-device-id branch[1] and updated the bug[2].
Would it make sense to squash the development history? I don't know how
many different commits would make sense. Right now I am only looking at
one diff that includes everything.
It adds a TODO:
+ if(hasPnpInfoService(uuids)) {
+ // TODO: Get the actual vendor and product ids.
+ DBusClientCall1<ServiceDict> discoverServices(*this,
+
"DiscoverServices");
What does that mean? Is there work left to do and is it tracked in bugs.meego.com?
+ if(pos != std::string::npos)
+ {
Not my favorite bracket style, but so be it...
+static string SyncEvolutionDataDir()
+{
+ string dataDir(DATA_DIR);
+ const char *envvar = getenv("SYNCEVOLUTION_DATA_DIR");
+ if (envvar) {
+ dataDir = envvar;
+ }
+ return dataDir;
+}
This new env variable needs to be documented in README.rst. A better place for this
function might be in util.h/cpp.
+static bool getPnpInfoNamesFromValues(const std::string &vendorValue, std::string
&vendorName,
+ const std::string &productValue, std::string
&productName)
+{
+ static GKeyFile *bt_key_vals = NULL;
+
+ if(!bt_key_vals) {
+ bt_key_vals = g_key_file_new();
+ GError *err = NULL;
+ string filePath(SyncEvolutionDataDir() + "/bluetooth_products.ini");
The syncevo-dbus-server has a feature where it watches files that make
up the running process and restarts when any of those change. System
daemons do that via package scripts, but for daemons started in a
session that doesn't work. The SyncEvolution mechanism currently works
for the executable and shared libraries, automatically found from
scanning /proc/self/maps.
Data files are loaded anew when needed (XML config files, for example).
Doing that for every getPnpInfoNamesFromValues() might be a bit often.
Perhaps the result can be cached in the D-Bus session instance instead
of in a static variable?
Or you could manually add that file to the watch list. See
DBusServer::run().
+ if(vendor)
+ vendorName = vendor;
+ else
+ // We at least need a vendor id match.
+ return false;
Now *that's* the (non-)bracket style which I once declared unacceptable
for SyncEvolution ;-) I know, I should replace the reference to the
Funambol coding style in the HACKING document with some actual rules.
Please, always use brackets even around single statements.
+ /** callback of 'DiscoverServices' method. The serve detals are retrieved
*/
+ void discoverServicesCb(const ServiceDict &serviceDict, const std::string
&error);
Typo. Really minor. Consider it a feeble attempt at demonstrating that I
have read the patch.
for(syncDevIt = m_syncDevices.begin(); syncDevIt != m_syncDevices.end(); ++syncDevIt)
{
if(boost::equals(syncDevIt->m_deviceId, deviceId)) {
device = *syncDevIt;
+ if(syncDevIt->m_pnpInformation)
+ {
Switching coding style in the middle of some other code looks weird.
--- a/test/test-dbus.py
+++ b/test/test-dbus.py
@@ -53,6 +53,10 @@ monitor = ["dbus-monitor"]
# primarily for XDG files, but also other temporary files
xdg_root = "temp-test-dbus"
configName = "dbus_unittest"
+# for bluetooth tests. replace with values from your test device.
+bt_device_mac = "D4:5D:42:73:E4:6C"
+bt_device_fingerprint = "Nokia 5230"
+bt_device_name = "Nokia 5230a"
Replace how? By editing the script? I know that I have set a bad
precedent by using the same approach for enabling gdb, but that is rare.
A better mechanism for the device would be useful - command line
parameter or env variable? Or perhaps better simulate a desktop
environment with various paired Bluetooth devices by registering a mock
org.bluez implementation on the D-Bus session bus and using it in
syncevo-dbus-server when a certain env variable is set? See
DBUS_TEST_CONNMAN for an example.
There are some white space changes in test-dbus.py. I assume that that's
cleanup work which will be a separate patch.
--
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.
2:10 a.m.
On Thu, Aug 18, 2011 at 4:03 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mo, 2011-08-15 at 15:05 +0200, Chris Kühl wrote:
> Also, I think I'm pretty much done Bluetooth work. I've commit my
> changes to the bluetooth-device-id branch[1] and updated the bug[2].
Would it make sense to squash the development history? I don't know how
many different commits would make sense. Right now I am only looking at
one diff that includes everything.
Absolutely. I've squashed it into 2 commits; one for the server code
and another for the tests. You can find it in the
bluetooth-device-id-merge-prep branch.
It adds a TODO:
+ if(hasPnpInfoService(uuids)) {
+ // TODO: Get the actual vendor and product ids.
+ DBusClientCall1<ServiceDict> discoverServices(*this,
+
"DiscoverServices");
What does that mean? Is there work left to do and is it tracked in bugs.meego.com?
Oop. That's old. Removed now
+ if(pos != std::string::npos)
+ {
Not my favorite bracket style, but so be it...
Think I've changed them all to open on the same line as the if
statement now. [Grumbles about function and if statement braces being
different. ;)]
+static string SyncEvolutionDataDir()
+{
+ string dataDir(DATA_DIR);
+ const char *envvar = getenv("SYNCEVOLUTION_DATA_DIR");
+ if (envvar) {
+ dataDir = envvar;
+ }
+ return dataDir;
+}
This new env variable needs to be documented in README.rst. A better place for this
function might be in util.h/cpp.
Ok I've updated README.rst and moved it to utils.
This is just a copy of SyncEvolutionTemplateDir which is static in
SyncConfig.cpp. I'll make a separate commit to do the same with that,
too.
+static bool getPnpInfoNamesFromValues(const std::string &vendorValue, std::string
&vendorName,
+ const std::string &productValue, std::string
&productName)
+{
+ static GKeyFile *bt_key_vals = NULL;
+
+ if(!bt_key_vals) {
+ bt_key_vals = g_key_file_new();
+ GError *err = NULL;
+ string filePath(SyncEvolutionDataDir() + "/bluetooth_products.ini");
The syncevo-dbus-server has a feature where it watches files that make
up the running process and restarts when any of those change. System
daemons do that via package scripts, but for daemons started in a
session that doesn't work. The SyncEvolution mechanism currently works
for the executable and shared libraries, automatically found from
scanning /proc/self/maps.
Data files are loaded anew when needed (XML config files, for example).
Doing that for every getPnpInfoNamesFromValues() might be a bit often.
Perhaps the result can be cached in the D-Bus session instance instead
of in a static variable?
Or you could manually add that file to the watch list. See
DBusServer::run().
Ah, yes. I did notice that code but had forgotten about it.
+ if(vendor)
+ vendorName = vendor;
+ else
+ // We at least need a vendor id match.
+ return false;
Now *that's* the (non-)bracket style which I once declared unacceptable
for SyncEvolution ;-) I know, I should replace the reference to the
Funambol coding style in the HACKING document with some actual rules.
Please, always use brackets even around single statements.
Sure, I should be done now.
+ /** callback of 'DiscoverServices' method. The serve
detals are retrieved */
+ void discoverServicesCb(const ServiceDict &serviceDict, const std::string
&error);
Typo. Really minor. Consider it a feeble attempt at demonstrating that I
have read the patch.
Thanks. Fixed.
for(syncDevIt = m_syncDevices.begin(); syncDevIt !=
m_syncDevices.end(); ++syncDevIt) {
if(boost::equals(syncDevIt->m_deviceId, deviceId)) {
device = *syncDevIt;
+ if(syncDevIt->m_pnpInformation)
+ {
Switching coding style in the middle of some other code looks weird.
What can I say? I like variety. ;) Fixed.
--- a/test/test-dbus.py
+++ b/test/test-dbus.py
@@ -53,6 +53,10 @@ monitor = ["dbus-monitor"]
# primarily for XDG files, but also other temporary files
xdg_root = "temp-test-dbus"
configName = "dbus_unittest"
+# for bluetooth tests. replace with values from your test device.
+bt_device_mac = "D4:5D:42:73:E4:6C"
+bt_device_fingerprint = "Nokia 5230"
+bt_device_name = "Nokia 5230a"
Replace how? By editing the script? I know that I have set a bad
precedent by using the same approach for enabling gdb, but that is rare.
A better mechanism for the device would be useful - command line
parameter or env variable? Or perhaps better simulate a desktop
environment with various paired Bluetooth devices by registering a mock
org.bluez implementation on the D-Bus session bus and using it in
syncevo-dbus-server when a certain env variable is set? See
DBUS_TEST_CONNMAN for an example.
Ok, I see. I'll get this changed. Not in right now, though.
There are some white space changes in test-dbus.py. I assume that
that's
cleanup work which will be a separate patch.
Oops. I've removed those changes. These are in my test-dbus branch anyway.
Cheers,
Chris
8:53 p.m.
On Fri, Aug 19, 2011 at 6:10 PM, Chris Kühl <blixtra(a)gmail.com> wrote:
On Thu, Aug 18, 2011 at 4:03 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Mo, 2011-08-15 at 15:05 +0200, Chris Kühl wrote:
>
> +static bool getPnpInfoNamesFromValues(const std::string &vendorValue,
std::string &vendorName,
> + const std::string &productValue,
std::string &productName)
> +{
> + static GKeyFile *bt_key_vals = NULL;
> +
> + if(!bt_key_vals) {
> + bt_key_vals = g_key_file_new();
> + GError *err = NULL;
> + string filePath(SyncEvolutionDataDir() +
"/bluetooth_products.ini");
>
> The syncevo-dbus-server has a feature where it watches files that make
> up the running process and restarts when any of those change. System
> daemons do that via package scripts, but for daemons started in a
> session that doesn't work. The SyncEvolution mechanism currently works
> for the executable and shared libraries, automatically found from
> scanning /proc/self/maps.
>
> Data files are loaded anew when needed (XML config files, for example).
> Doing that for every getPnpInfoNamesFromValues() might be a bit often.
> Perhaps the result can be cached in the D-Bus session instance instead
> of in a static variable?
>
> Or you could manually add that file to the watch list. See
> DBusServer::run().
>
Ah, yes. I did notice that code but had forgotten about it.
I forgot to add here that I've added a file monitor to the
BluezManager class to take care of this. It's in a separate commit. on
the *merge_prep branch.
Cheers,
Chris
10:46 p.m.
On Fri, Aug 19, 2011 at 6:10 PM, Chris Kühl <blixtra(a)gmail.com> wrote:
On Thu, Aug 18, 2011 at 4:03 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
What can I say? I like variety. ;) Fixed.
> --- a/test/test-dbus.py
> +++ b/test/test-dbus.py
> @@ -53,6 +53,10 @@ monitor = ["dbus-monitor"]
> # primarily for XDG files, but also other temporary files
> xdg_root = "temp-test-dbus"
> configName = "dbus_unittest"
> +# for bluetooth tests. replace with values from your test device.
> +bt_device_mac = "D4:5D:42:73:E4:6C"
> +bt_device_fingerprint = "Nokia 5230"
> +bt_device_name = "Nokia 5230a"
>
> Replace how? By editing the script? I know that I have set a bad
> precedent by using the same approach for enabling gdb, but that is rare.
> A better mechanism for the device would be useful - command line
> parameter or env variable? Or perhaps better simulate a desktop
> environment with various paired Bluetooth devices by registering a mock
> org.bluez implementation on the D-Bus session bus and using it in
> syncevo-dbus-server when a certain env variable is set? See
> DBUS_TEST_CONNMAN for an example.
>
Ok, I see. I'll get this changed. Not in right now, though.
This is also done now. I think this is what you intended.
The bluetooth-device-id-merge-prep is ready to be reviewed now.
Cheers,
Chris
2:08 a.m.
On Mi, 2011-08-24 at 14:46 +0200, Chris Kühl wrote:
The bluetooth-device-id-merge-prep is ready to be reviewed now.
I've merged the D-Bus server reorganization, dbus-test and
bluetooth-device-id-merge-prep branches. I fixed some minor problems
found with -Werror -Wall.
Attached an updated revision of the bluetooth-device-id-inspector.py
script. Should we maintain it in SyncEvolution?
My changes:
- more information for the user
- allow the user to skip devices
- don't include vendor in example product name
- skip devices which have PNPINFO_UUID information, but are not
online at the moment (script used to abort with an exception)
- write the user provided vendor/model information into the file
even if PNPINFO_UUID information isn't supported
The last point avoids the situation where the user is asked to send you
a file which says "This phone does not support Device ID profile"
without telling you what phone it is ;-)
Do we want to gather information about that? I think we should for the
sake of completeness, although I am not sure what to do with it in that
case.
Here's an example run:
Device name: localhost.localdomain-0
MAC Address: 00:22:43:AF:07:0D
Supports SyncML.
What company makes this phone? (examples: Nokia, Sony Ericsson), empty to skip:
Device name: K750i
MAC Address: 00:0E:07:B1:90:17
Supports SyncML.
Looking up device information...
Failed, skipping device: org.bluez.Error.ConnectionAttemptFailed: Host is down
Device name: 6310i
MAC Address: 00:60:57:33:6C:0C
What company makes this phone? (examples: Nokia, Sony Ericsson), empty to skip: Nokia
What is the model of this phone? (example: N900, K750i), empty to skip: 6310i
Thanks, please send the file syncevo-phone-info-[6310i].txt to blixtra [at] gmail.com
Device name: Nokia N70
MAC Address: 00:17:4B:1D:28:B2
Supports SyncML.
What company makes this phone? (examples: Nokia, Sony Ericsson), empty to skip: Nokia
What is the model of this phone? (example: N900, K750i), empty to skip: N70
Thanks, please send the file syncevo-phone-info-[N70].txt to blixtra [at] gmail.com
Device name: Nokia N900
MAC Address: 80:50:1B:BE:AA:2B
Supports SyncML.
What company makes this phone? (examples: Nokia, Sony Ericsson), empty to skip: Nokia
What is the model of this phone? (example: N900, K750i), empty to skip: N900
Thanks, please send the file syncevo-phone-info-[N900].txt to blixtra [at] gmail.com
Device Name: Nokia N97 mini
MAC Address: A0:4E:04:1E:AD:30
Supports SyncML.
Looking up device information...
What company makes this phone? (examples: Nokia, Sony Ericsson), empty to skip: Nokia
What is the model of this phone? (example: N900, K750i), empty to skip: N97 mini
Device name: Nokia 7100s-2
MAC Address: C8:97:9F:5D:B7:FB
Supports SyncML.
Looking up device information...
Failed, skipping device: org.bluez.Error.ConnectionAttemptFailed: Host is down
Of the various Nokia phones, only some supported the Device ID profile
and I had only turned on the N97. All resulting files also attached.
When I tried this in combination with the GTK sync-ui, I found that my
"Nokia N97" (user chosen name) was sometimes shown as "Nokia",
sometimes
as "Nokia N97" in the UI.
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?
--
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.
2:12 a.m.
On Fr, 2011-08-26 at 18:08 +0200, Patrick Ohly wrote:
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?
It would make sense, because peerName was indeed not provided by the
syncevolution-dbus-server <= 1.2. Here's what it sends:
dict entry(
string "configName"
string
"_usr_share_syncevolution_templates_clients_phone_nokia.ini"
)
dict entry(
string "description"
string "Template for all Nokia phones which support contacts, notes
and combined tasks+events"
)
dict entry(
string "deviceId"
string "syncevolution-3d99e9ac-646a-491d-b473-1861ccc2de1a"
)
dict entry(
string "deviceName"
string "Nokia N97"
)
dict entry(
string "fingerPrint"
string "Nokia N900,Nokia N85,Nokia 7210c,Nokia N97 mini,Nokia
2630,Nokia 6500 Slide,Nokia 5800 XpressMusic,Nokia"
)
dict entry(
string "remoteIdentifier"
string "PC Suite"
)
dict entry(
string "score"
string "4"
)
dict entry(
string "syncURL"
string "obex-bt://A0:4E:04:1E:AD:30"
)
dict entry(
string "templateName"
string "Nokia"
)
--
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.
2:48 a.m.
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.
7:50 p.m.
2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
On Mi, 2011-08-24 at 14:46 +0200, Chris Kühl wrote:
> The bluetooth-device-id-merge-prep is ready to be reviewed now.
I've merged the D-Bus server reorganization, dbus-test and
bluetooth-device-id-merge-prep branches. I fixed some minor problems
found with -Werror -Wall.
Great!
Attached an updated revision of the bluetooth-device-id-inspector.py
script. Should we maintain it in SyncEvolution?
Makes sense. Should it go in test or should we create a
tools/utilities directory?
My changes:
- more information for the user
- allow the user to skip devices
- don't include vendor in example product name
- skip devices which have PNPINFO_UUID information, but are not
online at the moment (script used to abort with an exception)
Yeah, I ran into this after committing and never got around to updating. Thanks.
- write the user provided vendor/model information into the file
even if PNPINFO_UUID information isn't supported
The last point avoids the situation where the user is asked to send you
a file which says "This phone does not support Device ID profile"
without telling you what phone it is ;-)
Ah right. ;)
Do we want to gather information about that? I think we should for
the
sake of completeness, although I am not sure what to do with it in that
case.
Yes, I agree. It may be of interest to know which phones don't support
this feature, if only to give us some insight into what percentage of
phones do support the device id profile.
Here's an example run:
Device name: localhost.localdomain-0
MAC Address: 00:22:43:AF:07:0D
Supports SyncML.
What company makes this phone? (examples: Nokia, Sony Ericsson), empty to skip:
Device name: K750i
MAC Address: 00:0E:07:B1:90:17
Supports SyncML.
Looking up device information...
Failed, skipping device: org.bluez.Error.ConnectionAttemptFailed: Host is down
Device name: 6310i
MAC Address: 00:60:57:33:6C:0C
What company makes this phone? (examples: Nokia, Sony Ericsson), empty to skip: Nokia
What is the model of this phone? (example: N900, K750i), empty to skip: 6310i
Thanks, please send the file syncevo-phone-info-[6310i].txt to blixtra [at] gmail.com
Device name: Nokia N70
MAC Address: 00:17:4B:1D:28:B2
Supports SyncML.
What company makes this phone? (examples: Nokia, Sony Ericsson), empty to skip: Nokia
What is the model of this phone? (example: N900, K750i), empty to skip: N70
Thanks, please send the file syncevo-phone-info-[N70].txt to blixtra [at] gmail.com
Device name: Nokia N900
MAC Address: 80:50:1B:BE:AA:2B
Supports SyncML.
What company makes this phone? (examples: Nokia, Sony Ericsson), empty to skip: Nokia
What is the model of this phone? (example: N900, K750i), empty to skip: N900
Thanks, please send the file syncevo-phone-info-[N900].txt to blixtra [at] gmail.com
Device Name: Nokia N97 mini
MAC Address: A0:4E:04:1E:AD:30
Supports SyncML.
Looking up device information...
What company makes this phone? (examples: Nokia, Sony Ericsson), empty to skip: Nokia
What is the model of this phone? (example: N900, K750i), empty to skip: N97 mini
Device name: Nokia 7100s-2
MAC Address: C8:97:9F:5D:B7:FB
Supports SyncML.
Looking up device information...
Failed, skipping device: org.bluez.Error.ConnectionAttemptFailed: Host is down
Of the various Nokia phones, only some supported the Device ID profile
and I had only turned on the N97. All resulting files also attached.
When I tried this in combination with the GTK sync-ui, I found that my
"Nokia N97" (user chosen name) was sometimes shown as "Nokia",
sometimes
as "Nokia N97" in the UI.
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)
Right, I can make this change. But when you say "vendor/model is
available" you mean when the product and not *just* the vendor is in
the lookup table, right? That would make sense to me.
* templateName: the "templateName" from the template,
as it used
to (see above)
I wasn't aware I changed this. I'll take a closer look.
* 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.
Ok. I'll assume my above interpretation is correct until told differently.
Thanks for getting this merged.
Cheers,
Chris
8:25 p.m.
On Mo, 2011-08-29 at 11:50 +0200, Chris Kühl wrote:
2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
> On Mi, 2011-08-24 at 14:46 +0200, Chris Kühl wrote:
>> The bluetooth-device-id-merge-prep is ready to be reviewed now.
>
> I've merged the D-Bus server reorganization, dbus-test and
> bluetooth-device-id-merge-prep branches. I fixed some minor problems
> found with -Werror -Wall.
Great!
>
> Attached an updated revision of the bluetooth-device-id-inspector.py
> script. Should we maintain it in SyncEvolution?
>
Makes sense. Should it go in test or should we create a
tools/utilities directory?
At some point we should, but then we would also have to move some of the
other scripts. Let's add it to "test" to keep it simple for the time
being.
> 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)
Right, I can make this change. But when you say "vendor/model is
available" you mean when the product and not *just* the vendor is in
the lookup table, right? That would make sense to me.
IMHO it would make sense also if just the vendor is available. That
information is not provided to the UI otherwise.
But see my later email: after some more thinking I came to the
conclusion that "deviceName" should stay as it is (name chosen by the
user) and the new information should go into "templateName".
--
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.
10:03 p.m.
On Mon, Aug 29, 2011 at 12:25 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mo, 2011-08-29 at 11:50 +0200, Chris Kühl wrote:
> 2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
> > On Mi, 2011-08-24 at 14:46 +0200, Chris Kühl wrote:
> >> The bluetooth-device-id-merge-prep is ready to be reviewed now.
> >
> > I've merged the D-Bus server reorganization, dbus-test and
> > bluetooth-device-id-merge-prep branches. I fixed some minor problems
> > found with -Werror -Wall.
>
> Great!
>
> >
> > Attached an updated revision of the bluetooth-device-id-inspector.py
> > script. Should we maintain it in SyncEvolution?
> >
>
> Makes sense. Should it go in test or should we create a
> tools/utilities directory?
At some point we should, but then we would also have to move some of the
other scripts. Let's add it to "test" to keep it simple for the time
being.
> > 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)
>
> Right, I can make this change. But when you say "vendor/model is
> available" you mean when the product and not *just* the vendor is in
> the lookup table, right? That would make sense to me.
IMHO it would make sense also if just the vendor is available. That
information is not provided to the UI otherwise.
But see my later email: after some more thinking I came to the
conclusion that "deviceName" should stay as it is (name chosen by the
user) and the new information should go into "templateName".
Did you mean peerName instead of templateName?
From the what you are saying here...
Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> 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.
... I understand the following.
1) In the case that we have no PnPInformation info we have...
deviceName = User-modifiable name
peerName = User-modifiable name
2) In the case that we have PnPInformation info but no product match
in the lookup table we have...
deviceName = User-modifiable name
peerName = Vendor found in Lookup table
3) In the case that we have PnPInformation info and a product match in
the lookup table we have...
deviceName = User-modifiable name
peerName = Vendor + " " + Product found in Lookup table
Is this right?
Also, the templateName was and is simply the "templateName" field from
the template. The code is...
string TemplateConfig::getTemplateName() {
return m_metaProps["templateName"];
}
Should this be different? We could create a different template for
each class of phone.
Cheers,
Chris
11:12 p.m.
On Mo, 2011-08-29 at 14:03 +0200, Chris Kühl wrote:
On Mon, Aug 29, 2011 at 12:25 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Mo, 2011-08-29 at 11:50 +0200, Chris Kühl wrote:
>> 2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
> But see my later email: after some more thinking I came to the
> conclusion that "deviceName" should stay as it is (name chosen by the
> user) and the new information should go into "templateName".
Did you mean peerName instead of templateName?
Yes.
Patrick Ohly <patrick.ohly(a)intel.com> wrote:
>> 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.
>
... I understand the following.
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>]".
2) In the case that we have PnPInformation info but no product match
in the lookup table we have...
deviceName = User-modifiable name
peerName = Vendor found in Lookup table
Correct.
3) In the case that we have PnPInformation info and a product match
in
the lookup table we have...
deviceName = User-modifiable name
peerName = Vendor + " " + Product found in Lookup table
Is this right?
Yes.
Also, the templateName was and is simply the "templateName"
field from
the template. The code is...
string TemplateConfig::getTemplateName() {
return m_metaProps["templateName"];
}
Correct.
Should this be different? We could create a different template for
each class of phone.
I don't think anything around templateName needs to be changed.
--
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.
12:50 a.m.
On Mon, Aug 29, 2011 at 3:12 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mo, 2011-08-29 at 14:03 +0200, Chris Kühl wrote:
> On Mon, Aug 29, 2011 at 12:25 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > On Mo, 2011-08-29 at 11:50 +0200, Chris Kühl wrote:
> >> 2011/8/26 Patrick Ohly <patrick.ohly(a)intel.com>:
> > But see my later email: after some more thinking I came to the
> > conclusion that "deviceName" should stay as it is (name chosen by the
> > user) and the new information should go into "templateName".
>
> Did you mean peerName instead of templateName?
Yes.
> Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> >> 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.
> >
>
> ... I understand the following.
>
> 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>]".
> 2) In the case that we have PnPInformation info but no product match
> in the lookup table we have...
>
> deviceName = User-modifiable name
> peerName = Vendor found in Lookup table
Correct.
> 3) In the case that we have PnPInformation info and a product match in
> the lookup table we have...
>
> deviceName = User-modifiable name
> peerName = Vendor + " " + Product found in Lookup table
>
> Is this right?
Yes.
> Also, the templateName was and is simply the "templateName" field from
> the template. The code is...
>
> string TemplateConfig::getTemplateName() {
> return m_metaProps["templateName"];
> }
Correct.
> Should this be different? We could create a different template for
> each class of phone.
I don't think anything around templateName needs to be changed.
I believe the first patch I've attached takes care of the deviceName
and peerName meanings. The second patch just adds the bluetooth
inspector script to the "test" directory.
Cheers,
Chris
1:27 a.m.
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?
From your patch:
// This is the user-modifiable
device name. Could be shown in GUIs, for example
localConfigs.insert(pair<string, string>("peerName",
peerTemplate->m_peerName));
+ // This can be either the user-modifiable device name, vendor
+ // 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;
Was it simply easier to implement this way or do you prefer that
semantic of "peerName" in a template reported by the D-Bus server?
My concern is that if the D-Bus server always reports a value, the D-Bus
client won't be able to determine whether it has reliable information
about the manufacturer and model.
--
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.
8:33 p.m.
On Mon, Aug 29, 2011 at 5:27 PM, Patrick Ohly <patrick.ohly(a)intel.com> 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.
From your patch:
// This is the user-modifiable device name. Could be shown in GUIs, for
example
localConfigs.insert(pair<string, string>("peerName",
peerTemplate->m_peerName));
+ // This can be either the user-modifiable device name, vendor
+ // 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;
Was it simply easier to implement this way or do you prefer that
semantic of "peerName" in a template reported by the D-Bus server?
My concern is that if the D-Bus server always reports a value, the D-Bus
client won't be able to determine whether it has reliable information
about the manufacturer and model.
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.
I've also attached a n updated patch for the script. Just adds a
header with copyright and license info.
Cheers,
Chris
9:01 p.m.
On Di, 2011-08-30 at 12:33 +0200, Chris Kühl wrote:
On Mon, Aug 29, 2011 at 5:27 PM, Patrick Ohly
<patrick.ohly(a)intel.com> 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.
11:52 p.m.
On Tue, Sep 6, 2011 at 7:01 AM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Di, 2011-08-30 at 12:33 +0200, Chris Kühl wrote:
> On Mon, Aug 29, 2011 at 5:27 PM, Patrick Ohly <patrick.ohly(a)intel.com> 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).
Great. On vacation now but glad to see that get in and completed.
> 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.
True.
> I've also attached a n updated patch for the script. Just adds a
> header with copyright and license info.
Also merged.
I'll make publish the blog post within the next couple days.
Cheers,
Chris
11:32 p.m.
On Thu, 2011-08-18 at 16:03 +0200, Patrick Ohly wrote:
+static string SyncEvolutionDataDir()
+{
+ string dataDir(DATA_DIR);
+ const char *envvar = getenv("SYNCEVOLUTION_DATA_DIR");
+ if (envvar) {
+ dataDir = envvar;
+ }
+ return dataDir;
+}
This new env variable needs to be documented in README.rst. A better
place for this
function might be in util.h/cpp.
Is there even any need for an environment variable to override the
default location? Just for testing?
--
murrayc(a)murrayc.com
www.murrayc.com
www.openismus.com
11:39 p.m.
On Mo, 2011-08-22 at 15:32 +0200, Murray Cumming wrote:
On Thu, 2011-08-18 at 16:03 +0200, Patrick Ohly wrote:
> +static string SyncEvolutionDataDir()
> +{
> + string dataDir(DATA_DIR);
> + const char *envvar = getenv("SYNCEVOLUTION_DATA_DIR");
> + if (envvar) {
> + dataDir = envvar;
> + }
> + return dataDir;
> +}
>
> This new env variable needs to be documented in README.rst. A better
> place for this
> function might be in util.h/cpp.
Is there even any need for an environment variable to override the
default location? Just for testing?
Primarily for testing. A secondary, less important use case is that some
users might not have root access on a machine and thus might be forced
to run pre-compiled binaries in a non-standard location. That works when
setting the env variables right. The HTTP server HOWTO explained that.
I'm running SyncEvolution like that for my own use on estamos.de
That reminds me: syncevo-http-server sets all these env variables when
asked to. SYNCEVOLUTION_DATA_DIR must be added there.
--
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.
11:51 p.m.
On Mon, Aug 22, 2011 at 3:39 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mo, 2011-08-22 at 15:32 +0200, Murray Cumming wrote:
> On Thu, 2011-08-18 at 16:03 +0200, Patrick Ohly wrote:
> > +static string SyncEvolutionDataDir()
> > +{
> > + string dataDir(DATA_DIR);
> > + const char *envvar = getenv("SYNCEVOLUTION_DATA_DIR");
> > + if (envvar) {
> > + dataDir = envvar;
> > + }
> > + return dataDir;
> > +}
> >
> > This new env variable needs to be documented in README.rst. A better
> > place for this
> > function might be in util.h/cpp.
>
> Is there even any need for an environment variable to override the
> default location? Just for testing?
Primarily for testing. A secondary, less important use case is that some
users might not have root access on a machine and thus might be forced
to run pre-compiled binaries in a non-standard location. That works when
setting the env variables right. The HTTP server HOWTO explained that.
I'm running SyncEvolution like that for my own use on estamos.de
That reminds me: syncevo-http-server sets all these env variables when
asked to. SYNCEVOLUTION_DATA_DIR must be added there.
Done.
Cheers,
Chris
4030
days inactive
4064
days old
syncevolution@synevolution.org
28 comments
3 participants
participants (3)
-
Chris Kühl -
Murray Cumming -
Patrick Ohly