5:10 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=9216
Summary: Implement GetConfigs dbus call for direct sync
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: major
Priority: Undecided
Component: SyncEvolution
AssignedTo: yongsheng.zhu(a)intel.com
ReportedBy: congwu.chen(a)intel.com
QAContact: yanshuang.zheng(a)intel.com
CC: syncevolution(a)lists.intel.com
As we discussed in bugzilla 7089, GetConfigs need to be changed accordingly to
support direct sync and use the new Template Configuration api.
In particular, we have to:
1) Listen on Bluez to get a list of paired devices
2) In GetConfigs (true), we have to query against the underlying template
system via the device name we got from Bluez and create a list of templates for
each device, the templates need be stored per client session.
3) A later GetConfig in the same session would get the template created in the
previous step.
It is nice if we could detect correctly if the peer is a SyncEvolution based
implementation, thus we query against the template system via "SyncEvolution"
instead of the device name.
--
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.
5:11 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
Chen Congwu <congwu.chen(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |7089
--
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.
4:24 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #1 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-04 21:24:50 PST
---
GetConfigs has to get devices list from bluez. I doubt it may cause callers
timeout. Is it possible to return immediately and send signal once result is
ready?
--
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.
6:07 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |patrick.ohly(a)intel.com
--- Comment #2 from pohly <patrick.ohly(a)intel.com> 2010-02-04 23:07:05 PST ---
(In reply to comment #1)
GetConfigs has to get devices list from bluez. I doubt it may cause
callers
timeout. Is it possible to return immediately and send signal once result is
ready?
I thought we were going to buffer a list of connected devices. In that case
GetConfigs() just iterates that list without asking Bluez.
Congwu's presence code has such a list. It is in master. I haven't looked at
the details, though.
--
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.
11:53 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
jku <jku(a)linux.intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jku(a)linux.intel.com
--- Comment #3 from jku <jku(a)linux.intel.com> 2010-02-05 04:53:58 PST ---
I've got a very rough draft of device template selector UI done. Some comments:
New properties in current branch:
score - the score
description - the description of the template
fingerprint - the fingerprint of the template
devicename - the device name the template is for
What's the standard, should these be CamelCased?
I understood that devicename property would be a usable way to find out which
templates/configs should be shown in "Devices" list instead of
"Services" and
for templates this does work. However, the actual configurations don't seem to
include this property (and adding it by hand doesn't make it show up via
D-Bus).
Also, is syncURL missing in the templates?
--
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.
1:11 a.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #4 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-05 06:11:55 PST
---
(In reply to comment #3)
I've got a very rough draft of device template selector UI done.
Some comments:
New properties in current branch:
score - the score
Currently the maximum of score is 3. It should be standardized
and normalized
(0 ~1）.
description - the description of the template
fingerprint - the fingerprint of the template
devicename - the device name the template is for
What's the standard, should these be CamelCased?
ok, I'll changed 2 of
them: 'fingerPrint' and 'deviceName'
I understood that devicename property would be a usable way to find
out which
templates/configs should be shown in "Devices" list instead of
"Services" and
for templates this does work. However, the actual configurations don't seem to
include this property (and adding it by hand doesn't make it show up via
D-Bus).
yes, but I don't quite understand what you mean. No need for this
information?
Also, is syncURL missing in the templates?
Because the template
is syncml client so syncURL is empty and thus syncURL of
the template should be replaced with the mac address of bluetooth here?
--
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.
1:24 a.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #5 from pohly <patrick.ohly(a)intel.com> 2010-02-05 06:24:27 PST ---
(In reply to comment #4)
(In reply to comment #3)
> I've got a very rough draft of device template selector UI done. Some comments:
>
> New properties in current branch:
> score - the score
Currently the maximum of score is 3. It should be standardized and normalized
(0 ~1）.
> description - the description of the template
> fingerprint - the fingerprint of the template
> devicename - the device name the template is for
>
> What's the standard, should these be CamelCased?
ok, I'll changed 2 of them: 'fingerPrint' and 'deviceName'
Property names are not case sensitive. Same rule as with config names: send the
normalized name (which is indeed CamelCase, for historic reasons with lower
initial letter, although that wasn't done consistently later on), accept any
kind of case.
> I understood that devicename property would be a usable way to
find out which
> templates/configs should be shown in "Devices" list instead of
"Services" and
> for templates this does work. However, the actual configurations don't seem to
> include this property (and adding it by hand doesn't make it show up via
> D-Bus).
yes, but I don't quite understand what you mean. No need for this information?
"devicename" cannot be stored in a config.ini. It gets added for the templates
on-the-fly in the syncevo-dbus-server.
Perhaps we should better use peerIsClient==1 to detect "devices"?
> Also, is syncURL missing in the templates?
Because the template is syncml client so syncURL is empty and thus syncURL of
the template should be replaced with the mac address of bluetooth here?
Yes, but the syncURL must be set by the syncevo-dbus-server. The sync-ui has no
way of determining what the MAC address of the device is.
--
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.
1:42 a.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #6 from jku <jku(a)linux.intel.com> 2010-02-05 06:42:34 PST ---
(In reply to comment #4)
> I understood that devicename property would be a usable way to
find out
> which templates/configs should be shown in "Devices" list instead of
> "Services" and for templates this does work. However, the actual
> configurations don't seem to include this property (and adding it by hand
> doesn't make it show up via D-Bus).
yes, but I don't quite understand what you mean. No need for this information?
I need a way to divide configurations into "Devices" and "Services".
It doesn't
have to happen using devicename, but I need to know how I should do that
dividing. syncURL parsing is one possibility.
Also, I need a way to match a device config with all templates that concern the
same device. syncURL sounds like the right choice again as there is the chance
that there are two paired devices with the same devicename.
> Also, is syncURL missing in the templates?
Because the template is syncml client so syncURL is empty and thus syncURL of
the template should be replaced with the mac address of bluetooth here?
All device templates returned via the dbus api would be for a specific device,
correct? As a consequence I expected syncURL (bt address of that device) to be
there. How else can I save the configuration uses chooses with the syncURL in
it?
Just so we're on the same page: I expect something like this to work when
creating a new config:
* GetConfigs() + N * GetConfig(), populate the list of
configs/templates. For devices this means one entry per paired device
* user selects the device on the device list, picks the template to be
used (hopefully helped by your scoring)
* user clicks Save:
GetSession(), SetConfig() with the selected template configuration
The only changes I intend to do before SetConfig() would be to set source sync
modes and setting peerName... Modifying device syncURL doesn't make much sense
for a user so it's not even exposed in the UI.
--
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.
2:01 a.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #7 from jku <jku(a)linux.intel.com> 2010-02-05 07:01:10 PST ---
(In reply to comment #5)
Perhaps we should better use peerIsClient==1 to detect
"devices"?
That sounds good enough for me. Let's deal with more complex setups as we go
along...
--
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.
2:28 a.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #8 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-05 07:28:58 PST
---
"devicename" cannot be stored in a config.ini. It gets
added for the templates
on-the-fly in the syncevo-dbus-server.
of course it is on the fly. It is added in
the GetConfig temporarily, gotten
from bluez.
Perhaps we should better use peerIsClient==1 to detect
"devices"?
Actually we'll use it for calculating scores.
> > Also, is syncURL missing in the templates?
> Because the template is syncml client so syncURL is empty and thus syncURL of
> the template should be replaced with the mac address of bluetooth here?
Yes, but the syncURL must be set by the syncevo-dbus-server. The sync-ui has no
way of determining what the MAC address of the device is.
Yes, of course.
--
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.
2:33 a.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #9 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-05 07:33:04 PST
---
(In reply to comment #6)
(In reply to comment #4)
> > I understood that devicename property would be a usable way to find out
> > which templates/configs should be shown in "Devices" list instead of
> > "Services" and for templates this does work. However, the actual
> > configurations don't seem to include this property (and adding it by hand
> > doesn't make it show up via D-Bus).
> yes, but I don't quite understand what you mean. No need for this information?
I need a way to divide configurations into "Devices" and "Services".
It doesn't
have to happen using devicename, but I need to know how I should do that
dividing. syncURL parsing is one possibility.
Also, I need a way to match a device config with all templates that concern the
same device. syncURL sounds like the right choice again as there is the chance
that there are two paired devices with the same devicename.
> > Also, is syncURL missing in the templates?
> Because the template is syncml client so syncURL is empty and thus syncURL of
> the template should be replaced with the mac address of bluetooth here?
All device templates returned via the dbus api would be for a specific device,
correct? As a consequence I expected syncURL (bt address of that device) to be
there. How else can I save the configuration uses chooses with the syncURL in
it?
Just so we're on the same page: I expect something like this to work when
creating a new config:
* GetConfigs() + N * GetConfig(), populate the list of
configs/templates. For devices this means one entry per paired device
yes, entry
here means the entry in the UI, each with many templates.
* user selects the device on the device list, picks the template to
be
used (hopefully helped by your scoring)
* user clicks Save:
GetSession(), SetConfig() with the selected template configuration
The only changes I intend to do before SetConfig() would be to set source sync
modes and setting peerName... Modifying device syncURL doesn't make much sense
for a user so it's not even exposed in the UI.
Yes, you are right. I think
'syncURL' with the address of bluetooth device
could meet the above requirements, so you could group templates by device and
show devices list in the UI.
--
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.
4:43 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #10 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-07 21:43:25
PST ---
update it. please get the latest code.
1) getConfigs querys bluez synchronously if not done.
2) Signals of property changed are not listened. I'll do this in the next step.
--
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.
7:18 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #11 from jku <jku(a)linux.intel.com> 2010-02-09 00:18:04 PST ---
the branch now includes my UI work as well (as well as a couple of unrelated UI
fixes, apologies for those).
--
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.
4:55 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #12 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-20 21:55:14
PST ---
(In reply to comment #10)
update it. please get the latest code.
1) getConfigs querys bluez synchronously if not done.
Since querying devices is
done immediately after dbus server start up, I leave
it unchanged.
2) Signals of property changed are not listened. I'll do this in
the next step.
The code is ready on the branch 'mb9216'. Patrick, please
review and merge it.
--
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.
1:04 a.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #13 from pohly <patrick.ohly(a)intel.com> 2010-02-22 06:04:12 PST ---
(In reply to comment #12)
(In reply to comment #10)
> update it. please get the latest code.
> 1) getConfigs querys bluez synchronously if not done.
Since querying devices is done immediately after dbus server start up, I leave
it unchanged.
> 2) Signals of property changed are not listened. I'll do this in the next step.
The code is ready on the branch 'mb9216'. Patrick, please review and merge it.
The "usual" kind of remarks apply ;-}
/**
* Query bluetooth devices from bluez
*/
class BluezManager : public DBusRemoteObject {
...
/** callback of 'GetProperties' method */
void getPropertiesCb(const PropDict &props, const string &error);
/** callback of 'PropertyChanged' signal */
void propertyChanged(const string &name, const
boost::variant<vector<string>, string> &prop);
The source code comments hardly add any additional information. This would be a
good point to explain not just the purpose of the items, but also the overall
architecture (BluezManager) or what the individual callbacks do.
I know that several other existing comments are also not more verbose:
/** Server.SessionChanged */
EmitSignal2<const DBusObject_t &,
bool> sessionChanged;
But in those cases we have a full description elsewhere of what that signal
does.
Conceptually, the BluezManager::BluezAdapter::m_syncDevices might be in the
wrong place. What if there is more than one adapter or we need a similar
mechanism for other transports? IMHO m_syncDevices should be in DBusServer.
To implement Server.TemplatesChanged, I have to make make the emitter for that
signal public and trust that the relevant class (BluezManager) knows what to do
with it. To me that means that the current design doesn't pass the "smell
test". I'll let it stand as it is, but we might want to refactor at some point.
boost::shared_ptr<SignalWatch1<DBusObject_t> > m_deviceRemoved;
boost::shared_ptr<SignalWatch1<DBusObject_t> > m_deviceAdded;
...
boost::shared_ptr<PropertySignal> m_propertyChanged;
What is the reason for making these pointers rather than normal members?
Initialization order perhaps, because of the virtual methods? In that case we
might be going on about solving this the wrong way and should rather get rid of
the virtual methods.
I've added the TemplatesChanged on the mb9216_pohly branch. Jussi, does this
work for you? Untested, see below :-/
-------------------------------------------------------------------------
While testing the code, I found a problem: my K750i doesn't show up in the list
of device templates. I think I tracked it down to GetProperties() returning an
empty UUIDs list. From d-feet:
dbus.Dictionary({dbus.String(u'Name'): dbus.String(u'K750i',
variant_level=1),
dbus.String(u'Paired'): dbus.Boolean(True, variant_level=1),
dbus.String(u'Adapter'): dbus.ObjectPath('/hci0', variant_level=1),
dbus.String(u'Alias'): dbus.String(u'K750i', variant_level=1),
dbus.String(u'Connected'): dbus.Boolean(False, variant_level=1),
dbus.String(u'UUIDs'): dbus.Array([], signature=dbus.Signature('s'),
variant_level=1), dbus.String(u'Address'):
dbus.String(u'00:0E:07:B1:90:17',
variant_level=1), dbus.String(u'Class'): dbus.UInt32(5374468L,
variant_level=1), dbus.String(u'Trusted'): dbus.Boolean(False,
variant_level=1)}, signature=dbus.Signature('sv'))
Here's the corresponding output from sdptool:
$ sdptool search --bdaddr 00:0E:07:B1:90:17 SYNCML
Searching for SYNCML on 00:0E:07:B1:90:17 ...
Service Name: OBEX SyncML Client
Service RecHandle: 0x10007
Service Class ID List:
UUID 128: 00000002-0000-1000-8000-0002ee000002
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 7
"OBEX" (0x0008)
This is the UUID that BluezManager::BluezDevice::checkSyncService() looks for.
This is with bluez-utils 3.36-3 and bluez-gnome 0.27-1. Is my Bluez too old?
--
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.
1:05 a.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |9841
--
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.
3:22 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #14 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-22 20:22:17
PST ---
I know that several other existing comments are also not more
verbose:
/** Server.SessionChanged */
EmitSignal2<const DBusObject_t &,
bool> sessionChanged;
But in those cases we have a full description elsewhere of what that signal
does.
Conceptually, the BluezManager::BluezAdapter::m_syncDevices might be in the
wrong place. What if there is more than one adapter or we need a similar
mechanism for other transports? IMHO m_syncDevices should be in DBusServer.
We only
get the default adapter instead of all adapters for the default adapter
is in effect, right? So devices in the default adapter are checked and
listened.
Anyway, I agree to put it in the dbus server for there might be other
transports.
To implement Server.TemplatesChanged, I have to make make the emitter
for that
signal public and trust that the relevant class (BluezManager) knows what to do
with it. To me that means that the current design doesn't pass the "smell
test". I'll let it stand as it is, but we might want to refactor at some point.
'syncDeviceList is moved to DBusServer. Operations on it are also moved to
DBusServer. So 'templatesChanged' could be easily handled in them and of course
it should be 'private' now. They are:
DBusServer::addDevice, removeDevice, updateDevice.
boost::shared_ptr<SignalWatch1<DBusObject_t> >
m_deviceRemoved;
boost::shared_ptr<SignalWatch1<DBusObject_t> > m_deviceAdded;
...
boost::shared_ptr<PropertySignal> m_propertyChanged;
What is the reason for making these pointers rather than normal members?
Initialization order perhaps, because of the virtual methods? In that case we
might be going on about solving this the wrong way and should rather get rid of
the virtual methods.
ACK. BluezManager's signal should use boost::shared_ptr,
but BluezAdapter and
BluezDevice don't.
code is ready on branch 'mb9216'. please see it.
--
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.
7:29 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #15 from pohly <patrick.ohly(a)intel.com> 2010-02-23 00:29:28 PST ---
(In reply to comment #14)
> I know that several other existing comments are also not more
verbose:
> /** Server.SessionChanged */
> EmitSignal2<const DBusObject_t &,
> bool> sessionChanged;
> But in those cases we have a full description elsewhere of what that signal
> does.
>
> Conceptually, the BluezManager::BluezAdapter::m_syncDevices might be in the
> wrong place. What if there is more than one adapter or we need a similar
> mechanism for other transports? IMHO m_syncDevices should be in DBusServer.
We only get the default adapter instead of all adapters for the default adapter
is in effect, right?
I have no idea how Bluez works, so you tell me ;-)
So devices in the default adapter are checked and
listened.
That is probably a reasonable simplification, although I am still not sure
whether multiple adapters would work with Bluez.
Anyway, I agree to put it in the dbus server for there might be
other
transports.
The code looks much better now. However, the API of the new D-BusServer methods
is both awkward (why pass pairs instead of multiple parameters?) and not
documented at all. Therefore it is unclear what "deviceId" is:
+ /** methods to operate device list */
+ void getDeviceList(SyncConfig::DeviceList &devices);
+ bool getDevice(const string &deviceId, pair<string, pair<string,
SyncConfig::MatchMode> > &device);
+ void addDevice(const pair<string, pair<string, SyncConfig::MatchMode> >
&device);
+ void removeDevice(const string &deviceId);
+ void updateDevice(const string &deviceId, const pair<string, pair<string,
SyncConfig::MatchMode> > &device);
If you want to revise that once more, please do soon. Otherwise I'll probably
merge it as it is in a few hours.
--
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.
7:47 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #16 from pohly <patrick.ohly(a)intel.com> 2010-02-23 00:47:41 PST ---
(In reply to comment #13)
While testing the code, I found a problem: my K750i doesn't show
up in the list
of device templates. I think I tracked it down to GetProperties() returning an
empty UUIDs list.
[...]
This is with bluez-utils 3.36-3 and bluez-gnome 0.27-1. Is my Bluez
too old?
Yongsheng, any comments on this? Which Bluez packages do you test with?
--
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.
7:51 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #17 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-23 00:51:54
PST ---
The code looks much better now. However, the API of the new
D-BusServer methods
is both awkward (why pass pairs instead of multiple parameters?) and not
documented at all. Therefore it is unclear what "deviceId" is:
DeviceList
has statements about these parameters.
The element of DeviceList is also defined there, so I don't duplicate them
here.
why pass pairs instead of multiple parameters?
The pair is the
element type of DeviceList. See DeviceList definition. Maybe we
should re-define a new class to represent it instead of using std::pair.
--
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.
7:54 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #18 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-23 00:54:12
PST ---
(In reply to comment #16)
(In reply to comment #13)
> While testing the code, I found a problem: my K750i doesn't show up in the list
> of device templates. I think I tracked it down to GetProperties() returning an
> empty UUIDs list.
[...]
> This is with bluez-utils 3.36-3 and bluez-gnome 0.27-1. Is my Bluez too old?
Yongsheng, any comments on this? Which Bluez packages do you test with?
my
bluez-utils is 4.51-0. You may have a try. I wonder it's because phone's
bluetooth version.
--
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.
8:09 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #19 from pohly <patrick.ohly(a)intel.com> 2010-02-23 01:09:25 PST ---
(In reply to comment #17)
> The code looks much better now. However, the API of the new
D-BusServer methods
> is both awkward (why pass pairs instead of multiple parameters?) and not
> documented at all. Therefore it is unclear what "deviceId" is:
DeviceList has statements about these parameters.
The element of DeviceList is also defined there, so I don't duplicate them
here.
That makes sense, but wasn't obvious from the functions. Using
DeviceList::value_type instead of pair<...> would make your intention explicit.
> why pass pairs instead of multiple parameters?
The pair is the element type of DeviceList. See DeviceList definition. Maybe we
should re-define a new class to represent it instead of using std::pair.
Yes, I think that would have been cleaner. pair<> is okay for quick, local data
structures, but not having names for members makes the code harder to read.
Here we even have a triple, composed of two pairs. I know, not your code ;-}
--
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.
8:53 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
--- Comment #20 from yongsheng zhu <yongsheng.zhu(a)intel.com> 2010-02-23 01:53:16
PST ---
please merge the branch 'mb9216'.
--
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.
11:53 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |9863
--
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.
11:55 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #21 from pohly <patrick.ohly(a)intel.com> 2010-02-23 04:55:01 PST ---
(In reply to comment #20)
please merge the branch 'mb9216'.
Done, together with the TemplatesChanged signal.
For the bluez 3.36 issue I created bug #9863.
--
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.
3:30 a.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |INTEGRATED
--- Comment #22 from pohly <patrick.ohly(a)intel.com> 2010-02-24 08:29:58 PST ---
Integrated in 1.0 beta 2 = 0.99.11. To verify this, pair a new device while
sync-ui is running and has its device configuration dialog open. The sync-ui
should update its list and show the newly paired device.
--
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.
5:16 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
ZhangJingke <jingke.zhang(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
CC| |jingke.zhang(a)intel.com
--- Comment #23 from ZhangJingke <jingke.zhang(a)intel.com> 2010-03-01 22:15:54 PST
---
(In reply to comment #22)
Integrated in 1.0 beta 2 = 0.99.11. To verify this, pair a new device
while
sync-ui is running and has its device configuration dialog open. The sync-ui
should update its list and show the newly paired device.
Thanks Patrick for so clear verification steps. I can verify it in
syncevolution-0.9.99.11 by steps:
1. Pair with nokia_7210c and add it into syncUI->bluetooth device
2. Keep syncUI launched.
3. In bluetooth applet, pair with another phone nokia_5800.
4. When pairing was done, the 5800 device was added into device list
automatically. Now, we have 2 bluetooth devices to use.
--
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.
12:49 p.m.
New subject: [Bug 9216] Implement GetConfigs dbus call for direct sync
http://bugzilla.moblin.org/show_bug.cgi?id=9216
Bug 9216 depends on bug 9863, which changed state.
Bug 9863 Summary: Debian Etch + bluez-utils 3.36: no SyncML capable devices found
http://bugzilla.moblin.org/show_bug.cgi?id=9863
What |Old Value |New Value
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |MIGRATED
--
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.
4527
days inactive
4619
days old
syncevolution-issues@syncevolution.org
27 comments
1 participants
participants (1)
-
bugzilla＠moblin.org