10:15 p.m.
http://bugzilla.moblin.org/show_bug.cgi?id=7838
Summary: creating client configurations
Classification: Moblin Projects
Product: SyncEvolution
Version: upstream
Platform: Netbook
OS/Version: Moblin Linux
Status: ASSIGNED
Severity: major
Priority: P2
Component: *Feature Request
AssignedTo: syncevolution(a)lists.intel.com
ReportedBy: patrick.ohly(a)intel.com
CC: syncevolution(a)lists.intel.com
Right now, SyncEvolution as server expects that a configuration for a client
peer exists before the peer is able to synchronize (bug #7710). Creating the
configuration requires the client's device ID.
Here's the catch 22: that device ID typically cannot be determined unless the
client synchronizes or at least attempts to synchronize...
We could break that bind by:
- allowing the client to connect
- determine that it has no config yet
- ask the user whether he wants to allow the client to
connect and how
- create the config
- continue with it
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
11:20 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |7214
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
7:53 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |7873
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
1:49 a.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #1 from pohly <patrick.ohly(a)intel.com> 2009-12-02 06:49:20 PST ---
(In reply to comment #0)
Right now, SyncEvolution as server expects that a configuration for a
client
peer exists before the peer is able to synchronize (bug #7710).
This is true for all transports.
Creating the
configuration requires the client's device ID.
That is only true for HTTP. With OBEX, the right client config is found by
matching the client's MAC address against the syncURL.
Here's the catch 22: that device ID typically cannot be
determined unless the
client synchronizes or at least attempts to synchronize...
We could break that bind by:
- allowing the client to connect
- determine that it has no config yet
- ask the user whether he wants to allow the client to
connect and how
- create the config
- continue with it
That still looks like the right solution for HTTP.
For OBEX, simply scanning+pairing provides enough information to set the
syncURL correctly.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
2:18 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
Chen Congwu <congwu.chen(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |congwu.chen(a)intel.com
AssignedTo|syncevolution(a)lists.intel.c |congwu.chen(a)intel.com
|om |
--- Comment #2 from Chen Congwu <congwu.chen(a)intel.com> 2009-12-14 19:18:30 PST
---
(In reply to comment #1)
I will summarize as below:
1, Client inited sync scenario (Typically but not limited HTTP transport)
1a, Client side: should use a built-in template to generate the configuration
for the server. 'SyncURL' is used to uniquely identify the server (If multiple
servers locating on the same host, they should have different URL).
1b, Server side: the configuration should be created automatically when the
client first attempts to sync. 'remoteDeviceID' is used to uniquely identify
the client.
2, Server inited sync scenario (Typically but not limited Bluetooth transport)
2a, Client side: built-in by phone or created automatically during the server's
first sync attempt. "SyncURL" is used to uniquely identify the client (A client
configuration created to sync with "server1" should set its 'SyncURL'
to
"server1").
2b, Server side: created via a built-in template, 'remoteIdentifier' and
'deviceID' is used to help the client to uniquely identify the server
I also noticed the 'SyncURL' usage in 2a is not documented at this time.
(In reply to comment #0)
> Right now, SyncEvolution as server expects that a configuration for a client
> peer exists before the peer is able to synchronize (bug #7710).
This is true for all transports.
> Creating the
> configuration requires the client's device ID.
That is only true for HTTP. With OBEX, the right client config is found by
matching the client's MAC address against the syncURL.
Do you mean this in 1b?
Why not use the client's deviceID also the same as HTTP
transprot?
Or do you mean this in 2a but that goes to match against the 'SyncURL'
> Here's the catch 22: that device ID typically cannot be
determined unless the
> client synchronizes or at least attempts to synchronize...
>
> We could break that bind by:
> - allowing the client to connect
> - determine that it has no config yet
> - ask the user whether he wants to allow the client to
> connect and how
We need the user to authorize first and then goes to the
same process as the
generating the configuration based on a template. The remoteDeviceID is filled
in automatically.
> - create the config
> - continue with it
That still looks like the right solution for HTTP.
--
Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
8:54 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #3 from pohly <patrick.ohly(a)intel.com> 2009-12-15 01:54:52 PST ---
(In reply to comment #2)
(In reply to comment #1)
I will summarize as below:
It's a bit hard to follow who identifies whom.
1, Client inited sync scenario (Typically but not limited HTTP
transport)
1a, Client side: should use a built-in template to generate the configuration
for the server. 'SyncURL' is used to uniquely identify the server (If multiple
servers locating on the same host, they should have different URL).
.. is used by the client to identify the server ...
1b, Server side: the configuration should be created automatically
when the
client first attempts to sync. 'remoteDeviceID' is used to uniquely identify
the client.
... used by the server ...
2, Server inited sync scenario (Typically but not limited Bluetooth
transport)
2a, Client side: built-in by phone or created automatically during the server's
first sync attempt. "SyncURL" is used to uniquely identify the client (A
client
configuration created to sync with "server1" should set its 'SyncURL'
to
"server1").
Here it gets a bit confusing. SyncURL is used by the server (in contrast to
1a!) with the "obex+bt://..." scheme to send the SAN.
On the client, are you suggesting that the server is also identified by its MAC
address in the SyncURL? Or do you mean that "server1" as sent as server
identifier in the SAN should be used as SyncURL? Using which scheme?
2b, Server side: created via a built-in template,
'remoteIdentifier' and
'deviceID' is used to help the client to uniquely identify the server
'deviceID' as sent by the client, 'remoteIdentifier' as stored on the
server.
That's identical to 1b and doesn't apply to server-initiated Bluetooth
sessions. The config on the server was already chosen earlier.
There's case 3: SyncML client contacts SyncML server via Bluetooth.
> (In reply to comment #0)
> > Creating the
> > configuration requires the client's device ID.
>
> That is only true for HTTP. With OBEX, the right client config is found by
> matching the client's MAC address against the syncURL.
Do you mean this in 1b?
No. I was thinking of case 3 and how a front-end for SyncEvolution could set up
configurations without running a SyncML session: in that case, the device ID of
the peer is unknown.
Why not use the client's deviceID also the same as HTTP
transprot?
If we create the configurations on-the-fly as part of a SyncML session, we can
do that. If we want to create them in advance, say, as part of a Bluetooth
pairing dialog, we can't.
My suggestion was that we allow pre-configuring Bluetooth-based configs without
running a SyncML session by using the MAC address in the SyncURL as fallback to
identify the OBEX peer.
--
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:38 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #4 from Chen Congwu <congwu.chen(a)intel.com> 2009-12-15 23:38:41 PST
---
(In reply to comment #3)
> 2, Server inited sync scenario (Typically but not limited
Bluetooth transport)
> 2a, Client side: built-in by phone or created automatically during the server's
> first sync attempt. "SyncURL" is used to uniquely identify the client (A
client
> configuration created to sync with "server1" should set its
'SyncURL' to
> "server1").
Here it gets a bit confusing. SyncURL is used by the server (in contrast to
1a!) with the "obex+bt://..." scheme to send the SAN.
On the client, are you suggesting that the server is also identified by its MAC
address in the SyncURL? Or do you mean that "server1" as sent as server
identifier in the SAN should be used as SyncURL? Using which scheme?
Here the
server will send it's identifier as "PC Suite" or it's deviceID as we
discussed.
Client when receiving this identifier in SAN, will use this identifier to find
the corresponding client side configuration. At this time (from the code), this
goes to matching 'SyncURL' property.
In this scenario, 'SyncURL' is actually not used because it is the server
contacting the client, so it looks reasonable.
Another problem is can we allow user change sync directions (server inited <->
client inited) without creating separated configurations?
> 2b, Server side: created via a built-in template,
'remoteIdentifier' and
> 'deviceID' is used to help the client to uniquely identify the server
'deviceID' as sent by the client, 'remoteIdentifier' as stored on the
server.
That's identical to 1b and doesn't apply to server-initiated Bluetooth
sessions. The config on the server was already chosen earlier.
Yes, the different
is configuration in 1b need to be created on the fly while
2b is pre-chosen.
There's case 3: SyncML client contacts SyncML server via
Bluetooth.
I think it's covered by case 1 (Client inited scenario).
> > (In reply to comment #0)
> Why not use the client's deviceID also the same as HTTP
> transprot?
If we create the configurations on-the-fly as part of a SyncML session, we can
do that. If we want to create them in advance, say, as part of a Bluetooth
pairing dialog, we can't.
I see the problem...
My suggestion was that we allow pre-configuring Bluetooth-based
configs without
running a SyncML session by using the MAC address in the SyncURL as fallback to
identify the OBEX peer.
Yes, agree.
--
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:11 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #5 from pohly <patrick.ohly(a)intel.com> 2009-12-16 00:11:26 PST ---
(In reply to comment #4)
(In reply to comment #3)
> > 2, Server inited sync scenario (Typically but not limited Bluetooth transport)
> > 2a, Client side: built-in by phone or created automatically during the
server's
> > first sync attempt. "SyncURL" is used to uniquely identify the client
(A client
> > configuration created to sync with "server1" should set its
'SyncURL' to
> > "server1").
>
> Here it gets a bit confusing. SyncURL is used by the server (in contrast to
> 1a!) with the "obex+bt://..." scheme to send the SAN.
>
> On the client, are you suggesting that the server is also identified by its MAC
> address in the SyncURL? Or do you mean that "server1" as sent as server
> identifier in the SAN should be used as SyncURL? Using which scheme?
Here the server will send it's identifier as "PC Suite" or it's
deviceID as we
discussed.
Because we don't know whether the server sends a "real" identifier or just
"PC
Suite", we cannot depend on it for picking the right config on the client. We
have to fall back to the matching via Bluetooth MAC address.
Client when receiving this identifier in SAN, will use this
identifier to find
the corresponding client side configuration. At this time (from the code), this
goes to matching 'SyncURL' property.
In this scenario, 'SyncURL' is actually not used because it is the server
contacting the client, so it looks reasonable.
Another problem is can we allow user change sync directions (server inited <->
client inited) without creating separated configurations?
We want to allow that. Therefore the SyncURL must be valid for the "client
initiated" Bluetooth sync. That is consistent with finding the config by
matching MAC address with SyncURL.
> There's case 3: SyncML client contacts SyncML server via
Bluetooth.
I think it's covered by case 1 (Client inited scenario).
The difference is that for Bluetooth, we can use the MAC address for finding
configs, something that we cannot do for HTTP.
> My suggestion was that we allow pre-configuring Bluetooth-based
configs without
> running a SyncML session by using the MAC address in the SyncURL as fallback to
> identify the OBEX peer.
Yes, agree.
So to summarize, the open problems right now are:
- matching of MAC address against SyncURL in client when receiving SAN
or if no match found, creating a Bluetooth config on-the-fly
- providing templates for paired Bluetooth device that the user
can use to set up a config manually on the server side (see bug #7089
and the mailing list discussion around maintaining a database with
client templates)
- creating a config on-the-fly for the HTTP server case,
initially without user interaction
Right?
The second point could be implemented by creating a special config with a
well-known name ("server"?) that defines all sources supported by the server
and a username/password pair that new clients have to match before a new config
is created for them.
Implementation will be a bit tricky. We have to start a Synthesis session with
the "server" config in read-only mode, then at the point when the client is
authenticated, create a new config and switch to that while proceeding with the
same SyncML session. This depends on deferring some of the operations currently
done at the start of a sync until that point when the client is authorized (bug
#7710). I can have a look, but might not get around to it this week.
Should the name of this special config be configurable? I think so, via a
shared sync property "serverConfig", with "server" as default value.
--
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:13 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |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.
8 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #6 from Chen Congwu <congwu.chen(a)intel.com> 2009-12-16 01:00:29 PST
---
(In reply to comment #5)
So to summarize, the open problems right now are:
- matching of MAC address against SyncURL in client when receiving SAN
or if no match found, creating a Bluetooth config on-the-fly
I see. To be
precise, the MAC address is only matched after failing match the
server identifier in SAN. If the peer correctly sent it's deviceID in SAN,
where is the deviceID matched against to? 'SyncURL' looks not the right
property.
- providing templates for paired Bluetooth device that the user
can use to set up a config manually on the server side (see bug #7089
and the mailing list discussion around maintaining a database with
client templates)
- creating a config on-the-fly for the HTTP server case,
initially without user interaction
Right?
The second point could be implemented by creating a special config with a
well-known name ("server"?) that defines all sources supported by the server
and a username/password pair that new clients have to match before a new config
is created for them.
Implementation will be a bit tricky. We have to start a Synthesis session with
the "server" config in read-only mode, then at the point when the client is
authenticated, create a new config and switch to that while proceeding with the
same SyncML session. This depends on deferring some of the operations currently
done at the start of a sync until that point when the client is authorized (bug
#7710). I can have a look, but might not get around to it this week.
Should the name of this special config be configurable? I think so, via a
shared sync property "serverConfig", with "server" as default value.
Looks good.
--
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.
10:22 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #7 from pohly <patrick.ohly(a)intel.com> 2009-12-16 03:22:35 PST ---
(In reply to comment #6)
(In reply to comment #5)
> So to summarize, the open problems right now are:
> - matching of MAC address against SyncURL in client when receiving SAN
> or if no match found, creating a Bluetooth config on-the-fly
I see. To be precise, the MAC address is only matched after failing match the
server identifier in SAN. If the peer correctly sent it's deviceID in SAN,
where is the deviceID matched against to? 'SyncURL' looks not the right
property.
My point is that we *cannot* match the SAN server ID against anything because
we don't know what it is. As you said, storing it in SyncURL would be wrong
conceptually and prevent client-initiated syncs with that server.
On the server side, we take care to send the unique deviceID in the SAN unless
configured otherwise, because some clients might depend on this; SyncEvolution
itself won't be one of those clients.
--
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:43 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #8 from Chen Congwu <congwu.chen(a)intel.com> 2009-12-17 17:43:25 PST
---
(In reply to comment #5)
- creating a config on-the-fly for the HTTP server case,
initially without user interaction
Right?
The second point could be implemented by creating a special config with a
well-known name ("server"?) that defines all sources supported by the server
and a username/password pair that new clients have to match before a new config
is created for them.
Implementation will be a bit tricky. We have to start a Synthesis session with
the "server" config in read-only mode, then at the point when the client is
authenticated, create a new config and switch to that while proceeding with the
same SyncML session. This depends on deferring some of the operations currently
done at the start of a sync until that point when the client is authorized (bug
#7710). I can have a look, but might not get around to it this week.
Should the name of this special config be configurable? I think so, via a
shared sync property "serverConfig", with "server" as default value.
Just wondering, is it helpful for the phone model detection, since we get get
the peer's SyncML devinfo, the 'Mod' and 'Man' gives precise enough
information.
--
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:13 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #9 from pohly <patrick.ohly(a)intel.com> 2009-12-17 23:13:36 PST ---
(In reply to comment #8)
(In reply to comment #5)
> - creating a config on-the-fly for the HTTP server case,
> initially without user interaction
>
> Right?
>
> The second point could be implemented by creating a special config with a
> well-known name ("server"?) that defines all sources supported by the
server
> and a username/password pair that new clients have to match before a new config
> is created for them.
>
> Implementation will be a bit tricky. We have to start a Synthesis session with
> the "server" config in read-only mode, then at the point when the client
is
> authenticated, create a new config and switch to that while proceeding with the
> same SyncML session. This depends on deferring some of the operations currently
> done at the start of a sync until that point when the client is authorized (bug
> #7710). I can have a look, but might not get around to it this week.
>
> Should the name of this special config be configurable? I think so, via a
> shared sync property "serverConfig", with "server" as default
value.
Just wondering, is it helpful for the phone model detection, since we get get
the peer's SyncML devinfo, the 'Mod' and 'Man' gives precise enough
information.
The problem is not about identifying the client. If no peer configuration
exists at all yet, how do you decide whether the client is allowed to connect?
Remember, this is the HTTP server use cases, with an HTTP server facing the
normal Internet - anyone could connect and attempt to synchronize your private
data.
--
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:32 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #10 from Chen Congwu <congwu.chen(a)intel.com> 2009-12-29 23:32:15 PST
---
(In reply to comment #5)
So to summarize, the open problems right now are:
- matching of MAC address against SyncURL in client when receiving SAN
or if no match found, creating a Bluetooth config on-the-fly
- providing templates for paired Bluetooth device that the user
can use to set up a config manually on the server side (see bug #7089
and the mailing list discussion around maintaining a database with
client templates)
Implemented in configuration-template branch.
- creating a config on-the-fly for the HTTP server case,
initially without user interaction
Still need to be done.
--
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:56 a.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #11 from pohly <patrick.ohly(a)intel.com> 2010-01-11 10:56:08 PST ---
(In reply to comment #10)
(In reply to comment #5)
> So to summarize, the open problems right now are:
> - matching of MAC address against SyncURL in client when receiving SAN
> or if no match found, creating a Bluetooth config on-the-fly
> - providing templates for paired Bluetooth device that the user
> can use to set up a config manually on the server side (see bug #7089
> and the mailing list discussion around maintaining a database with
> client templates)
Implemented in configuration-template branch.
That had been merged into master, but I think we need to discuss it further,
therefore I reverted master to the state before that merge.
Comments about the patch: builtin templates were removed. I consider this
feature useful for cases where someone compiles just a single binary that he
wants to copy around (like I recently did with the Android binary). Please
preserve builtin templates for *servers*. For clients we can rely on the
templates in the filesystem.
The file system templates should be minimal, like the Funambol and
ScheduleWorld templates were:
- no comments
- no properties which have the default value
The term "finger" doesn't describe to me what the values are. Perhaps
"fingerprint" would be better? Can you explain what that property does and what
possible values are? Jussi has to review that, because it is likely that he
will have to parse those values in the sync-UI.
You updated the unit test at the end of the patch series. If tests have to be
updated, then this should be done together with the patch that breaks them.
--
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:40 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #12 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-11 20:40:40 PST
---
(In reply to comment #11)
(In reply to comment #10)
> (In reply to comment #5)
>
> > So to summarize, the open problems right now are:
> > - matching of MAC address against SyncURL in client when receiving SAN
> > or if no match found, creating a Bluetooth config on-the-fly
> > - providing templates for paired Bluetooth device that the user
> > can use to set up a config manually on the server side (see bug #7089
> > and the mailing list discussion around maintaining a database with
> > client templates)
> Implemented in configuration-template branch.
That had been merged into master, but I think we need to discuss it further,
therefore I reverted master to the state before that merge.
Sorry, maybe too
hurry..
Comments about the patch: builtin templates were removed. I consider
this
feature useful for cases where someone compiles just a single binary that he
wants to copy around (like I recently did with the Android binary). Please
preserve builtin templates for *servers*. For clients we can rely on the
templates in the filesystem.
What servers do you want to preserve in particular?
All HTTP servers including
SyncEvolution? What about servers provided over Bluetooth such as Nokia N900?
I hope the template system should be complete and not specific for server or
client. The supporting two-solution approach will introduce code complexity and
runtime penalty. If you really want a standalone binary, we can add *one*
special built-in default template for your tweaking.
I thought about the good things about the previous built-in template approach:
each time we upgrade the configuration system, we only need to change one place
in the code without remembering updating all template files manually. However I
think this is an acceptable compromise.
The file system templates should be minimal, like the Funambol and
ScheduleWorld templates were:
- no comments
- no properties which have the default value
ACK.
The term "finger" doesn't describe to me what the
values are. Perhaps
"fingerprint" would be better? Can you explain what that property does and
what
possible values are? Jussi has to review that, because it is likely that he
will have to parse those values in the sync-UI.
"Finger: the matching string
for this template, it is a comma separated string
with each string modeled as: "Manufacture_Model". The first substring is also
used as the unique name to identify this template so that user can select the
template by this name."
Perhaps adding some examples would be better?
See:
Nokia 7210c: Nokia_7210c
SyncEvolution server: SyncEvolutionServer, SyncEvolution
ScheduleWorld: ScheduleWorld,default
SyncEvolution client: SyncEvolutionClient, SyncEvolution
You updated the unit test at the end of the patch series. If tests
have to be
updated, then this should be done together with the patch that breaks them.
ACK.
--
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:52 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #13 from pohly <patrick.ohly(a)intel.com> 2010-01-11 23:52:19 PST ---
(In reply to comment #12)
(In reply to comment #11)
> Comments about the patch: builtin templates were removed. I consider this
> feature useful for cases where someone compiles just a single binary that he
> wants to copy around (like I recently did with the Android binary). Please
> preserve builtin templates for *servers*. For clients we can rely on the
> templates in the filesystem.
What servers do you want to preserve in particular? All HTTP servers including
SyncEvolution?
Yes. Basically what is needed for the traditional HTTP SyncML client use case.
What about servers provided over Bluetooth such as Nokia N900?
No.
I hope the template system should be complete and not specific for
server or
client. The supporting two-solution approach will introduce code complexity and
runtime penalty.
Code complexity - yes, to some extend. Runtime penalty - that smells like
unnecessary optimization, beware of that pitfall.
Is it really that difficult? The code supported it before already and it wasn't
that horrible, was it?
There was some duplication because the Funambol and ScheduleWorld templates
were built-in as well as in the files. That was because at some point we had
icons for them. Without icons, we don't need the on-disk copy of templates and
could remove them.
If you really want a standalone binary, we can add *one*
special built-in default template for your tweaking.
I'd prefer to have the full set.
> The term "finger" doesn't describe to me what the
values are. Perhaps
> "fingerprint" would be better? Can you explain what that property does and
what
> possible values are? Jussi has to review that, because it is likely that he
> will have to parse those values in the sync-UI.
"Finger: the matching string for this template, it is a comma separated string
with each string modeled as: "Manufacture_Model".
What if <Manufacturer> or <Model> contain commas and/or underscores?
The first substring is also
used as the unique name to identify this template so that user can select the
template by this name."
Perhaps adding some examples would be better?
See:
Nokia 7210c: Nokia_7210c
SyncEvolution server: SyncEvolutionServer, SyncEvolution
ScheduleWorld: ScheduleWorld,default
SyncEvolution client: SyncEvolutionClient, SyncEvolution
Is "SyncEvolution" the manufacturer or the model 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.
7:15 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #14 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-12 00:15:17 PST
---
(In reply to comment #13)
(In reply to comment #12)
> (In reply to comment #11)
> > Comments about the patch: builtin templates were removed. I consider this
> > feature useful for cases where someone compiles just a single binary that he
> > wants to copy around (like I recently did with the Android binary). Please
> > preserve builtin templates for *servers*. For clients we can rely on the
> > templates in the filesystem.
> What servers do you want to preserve in particular? All HTTP servers including
> SyncEvolution?
Yes. Basically what is needed for the traditional HTTP SyncML client use case.
So
every time we later add a new HTTP server, we add it in the code; for mobile
devices we add it via template file out of source. What do you expect from
this?
I see no necessary or even improvement via this approach. It just adds
maintenance overhead.
> What about servers provided over Bluetooth such as Nokia N900?
No.
> I hope the template system should be complete and not specific for server or
> client. The supporting two-solution approach will introduce code complexity and
> runtime penalty.
Code complexity - yes, to some extend. Runtime penalty - that smells like
unnecessary optimization, beware of that pitfall.
Is it really that difficult? The code supported it before already and it wasn't
that horrible, was it?
It's not complex. I just seems to me not necessary.
There was some duplication because the Funambol and ScheduleWorld
templates
were built-in as well as in the files. That was because at some point we had
icons for them. Without icons, we don't need the on-disk copy of templates and
could remove them.
> If you really want a standalone binary, we can add *one*
> special built-in default template for your tweaking.
I'd prefer to have the full set.
I am still not convinced so far. If you
insist, I of course can follow your
approach.
> > The term "finger" doesn't describe to me what the values are.
Perhaps
> > "fingerprint" would be better? Can you explain what that property
does and what
> > possible values are? Jussi has to review that, because it is likely that he
> > will have to parse those values in the sync-UI.
> "Finger: the matching string for this template, it is a comma separated string
> with each string modeled as: "Manufacture_Model".
What if <Manufacturer> or <Model> contain commas and/or underscores?
Not considered so far. If there is really such strange manufacture or model, we
can fix that later.
> The first substring is also
> used as the unique name to identify this template so that user can select the
> template by this name."
> Perhaps adding some examples would be better?
> See:
> Nokia 7210c: Nokia_7210c
> SyncEvolution server: SyncEvolutionServer, SyncEvolution
> ScheduleWorld: ScheduleWorld,default
> SyncEvolution client: SyncEvolutionClient, SyncEvolution
Is "SyncEvolution" the manufacturer or the model here?
You can think
something like that.
--
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.
9:46 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #15 from pohly <patrick.ohly(a)intel.com> 2010-01-12 02:46:33 PST ---
(In reply to comment #14)
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Comments about the patch: builtin templates were removed. I consider this
> > > feature useful for cases where someone compiles just a single binary that
he
> > > wants to copy around (like I recently did with the Android binary).
Please
> > > preserve builtin templates for *servers*. For clients we can rely on the
> > > templates in the filesystem.
> > What servers do you want to preserve in particular? All HTTP servers including
> > SyncEvolution?
>
> Yes. Basically what is needed for the traditional HTTP SyncML client use case.
So every time we later add a new HTTP server, we add it in the code; for mobile
devices we add it via template file out of source.
Yes.
What do you expect from
this?
A useable single-file installation of SyncEvolution. I consider this a valuable
feature.
If you want to implement this in a different way, say, by defining all
templates as files and importing a subset (or even all) into the binary at
compile-time, then that would also be a viable solution.
The code looking for templates could use the install location if it is
available, otherwise use the built-in defaults. In that case it would be
either/or instead of "first files, then builtin". If you use an internal
abstraction layer for accessing templates, then it's even fairly clean.
> What if <Manufacturer> or <Model> contain commas
and/or underscores?
Not considered so far. If there is really such strange manufacture or model, we
can fix that later.
Once we role out 1.0 final and users start adding template files for their own
phones, they don't have the option of modifying the source code of the
syncevo-dbus-server or the sync-ui.
The question of parsing these strings is only relevant if we reliably need to
decompose the strings into <manufacturer> and <model>. This might not be
necessary at all. A fuzzy string match might do just fine. For a hierarchical
view of templates, we could split at _ (*any* underscore, regardless how many
there are) and treat the individual words as "most general" to "most
specific".
That would also work for future extensions, like Nokia_N7120c_v1,
Nokia_N7120c_v2.
--
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:52 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #16 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-12 04:52:52 PST
---
(In reply to comment #15)
A useable single-file installation of SyncEvolution. I consider this
a valuable
feature.
Okay, I see.
> > What if <Manufacturer> or <Model> contain
commas and/or underscores?
> Not considered so far. If there is really such strange manufacture or model, we
> can fix that later.
Once we role out 1.0 final and users start adding template files for their own
phones, they don't have the option of modifying the source code of the
syncevo-dbus-server or the sync-ui.
The question of parsing these strings is only relevant if we reliably need to
decompose the strings into <manufacturer> and <model>. This might not be
necessary at all. A fuzzy string match might do just fine. For a hierarchical
view of templates, we could split at _ (*any* underscore, regardless how many
there are) and treat the individual words as "most general" to "most
specific".
That would also work for future extensions, like Nokia_N7120c_v1,
Nokia_N7120c_v2.
I was thinking something different thus resulting a different
approach. I think
users will not add their own templates (do we have any command line/ui option
for this?), thus the templates is maintained by us.Why do normal user need
their own template? They only need their only configurations.
With this assumption, I compromised a little to make the finger(print) string
more technical to help a better match, with this approach:
Nokia_N7210 will never match to LG_N7210c;
Nokia_N700 match with Nokia_N7000 will have less score than Nokia_N700 match
with Nokia_N701
I consider these features useful.
--
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:38 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #17 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-13 23:38:25 PST
---
(In reply to comment #16)
(In reply to comment #15)
I have just updated the patch for
your comments expect below. Patrick, what do
you think about this? If you are happy with my approach, you may have a look
and merge now.
> The question of parsing these strings is only relevant if we
reliably need to
> decompose the strings into <manufacturer> and <model>. This might not
be
> necessary at all. A fuzzy string match might do just fine. For a hierarchical
> view of templates, we could split at _ (*any* underscore, regardless how many
> there are) and treat the individual words as "most general" to "most
specific".
> That would also work for future extensions, like Nokia_N7120c_v1,
> Nokia_N7120c_v2.
I was thinking something different thus resulting a different approach. I think
users will not add their own templates (do we have any command line/ui option
for this?), thus the templates is maintained by us.Why do normal user need
their own template? They only need their only configurations.
With this assumption, I compromised a little to make the finger(print) string
more technical to help a better match, with this approach:
Nokia_N7210 will never match to LG_N7210c;
Nokia_N700 match with Nokia_N7000 will have less score than Nokia_N700 match
with Nokia_N701
I consider these features useful.
--
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:12 a.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #18 from pohly <patrick.ohly(a)intel.com> 2010-01-14 06:12:52 PST ---
(In reply to comment #16)
(In reply to comment #15)
> A useable single-file installation of SyncEvolution. I consider this a valuable
> feature.
Okay, I see.
> > > What if <Manufacturer> or <Model> contain commas and/or
underscores?
> > Not considered so far. If there is really such strange manufacture or model,
we
> > can fix that later.
>
> Once we role out 1.0 final and users start adding template files for their own
> phones, they don't have the option of modifying the source code of the
> syncevo-dbus-server or the sync-ui.
>
> The question of parsing these strings is only relevant if we reliably need to
> decompose the strings into <manufacturer> and <model>. This might not
be
> necessary at all. A fuzzy string match might do just fine. For a hierarchical
> view of templates, we could split at _ (*any* underscore, regardless how many
> there are) and treat the individual words as "most general" to "most
specific".
> That would also work for future extensions, like Nokia_N7120c_v1,
> Nokia_N7120c_v2.
I was thinking something different thus resulting a different approach. I think
users will not add their own templates (do we have any command line/ui option
for this?), thus the templates is maintained by us.Why do normal user need
their own template? They only need their only configurations.
True for users. I was thinking of distributors who might want to add additional
templates.
With this assumption, I compromised a little to make the
finger(print) string
more technical to help a better match, with this approach:
Nokia_N7210 will never match to LG_N7210c;
Not at all? What if Company Foo and Bar both sell the identical device XYZ and
we only have a template for Foo_XYZ?
Nokia_N700 match with Nokia_N7000 will have less score than
Nokia_N700 match
with Nokia_N701
I consider these features useful.
I have no idea how well this matching will work in practice.
Some real examples:
./syncevolution --template ?Nokia_N7210c
Available configuration templates:
Nokia_7210c = Nokia 7210c phone 4
Nokia = Default templates for nokia phone 2
ServerDefault = server side default template 1
SyncEvolutionServer = SyncEvolution server side template 1
./syncevolution --template ?7210c
Available configuration templates:
Nokia = Default templates for nokia phone 1
Nokia_7210c = Nokia 7210c phone 1
ServerDefault = server side default template 1
SyncEvolutionServer = SyncEvolution server side template 1
IMHO the Nokia_7210c template should get a higher score in the
second case.
Overall the whole matching code seems way to complicated to me. A "longest
common subsequence" match and a score defined as "length of
subsequence"/"length of fingerprint in template" might provide more
intuitive
results. I have an implementation of LCS lying around somewhere. Ping me if you
want it.
Congwu, can you add the real templates together with
this patch and add unit tests for the code to the Cmdline tests?
This is a lot of complex code that at least I don't understand
just by reading it. This is useful regardless how we really implement
the matching.
To run with a controlled set of file templates you could copy
those as we do for PIM data and then run the tests with a
ScopedEnvChange templates("SYNCEVOLUTION_TEMPLATE_DIR",
"testcases/templates").
Regarding naming of the top-level src/templates/[client|server]
directories: this is ambiguous. Is a "server template" something to
be used *by* a SyncML client or by a SyncML server *for* a client?
Traditionally, SyncEvolution had "server templates" which were used
by a client. Your patch reverses the meaning by putting the
Funambol/ScheduleWorld templates into a "client" directory.
Perhaps we can avoid the ambiguity by using "clients" and "servers"
(plural)? "servers" makes it more obvious that the templates are
describing servers, to be used by one client. Same the other way
around for one server supporting multiple clients.
(In reply to comment #17)
I have just updated the patch for your comments expect below.
Patrick, what do
you think about this?
For general comments, see above.
Regarding the code, here's a diff for changes that I would find useful:
diff --git a/README b/README
index c80fd34..7de4391 100644
--- a/README
+++ b/README
@@ -320,7 +320,7 @@ a list of valid values.
sources, so if you want to change a source property of just one specific
sync source, then use "--configure --source-property ... <server>
<source>".
---template|-l <server name>|default|?
+--template|-l <server name>|default|?|?<device>
Can be used to select from one of the built-in default configurations
for known SyncML servers. Defaults to the <server> name, so --template
only has to be specified when creating multiple different configurations
@@ -330,6 +330,13 @@ a list of valid values.
Each template contains a pseudo-random device ID. Therefore setting the
"deviceId" sync property is only necessary when manually recreating a
configuration or when a more descriptive name is desired.
+ The available templates for different known SyncML servers are listed
+ when using a single question mark instead of a template name. When using
+ the ?<device> format, a fuzzy search for a template that might be suitable
+ for talking to such a device is done. The matching works best when using
+ <device> = <Manufacturer>_<Model>. The output in this mode gives the
+ template name followed by a short description and a rating how well the
+ template matches the device (higher is better).
--status|-t
The changes made to local data since the last synchronization are
diff --git a/src/syncevo-dbus-server.cpp b/src/syncevo-dbus-server.cpp
index 24ac449..aeddc21 100644
--- a/src/syncevo-dbus-server.cpp
+++ b/src/syncevo-dbus-server.cpp
@@ -2657,8 +2657,8 @@ void Connection::process(const Caller_t &caller,
SyncConfig::ConfigList servers = SyncConfig::getConfigs();
BOOST_FOREACH(const SyncConfig::ConfigList::value_type
&server,
servers) {
- SyncContext context(server.first);
- if (context.getSyncURL() == serverID) {
+ SyncConfig config(server.first);
+ if (config.getSyncURL() == serverID) {
config = server.first;
break;
}
@@ -2672,9 +2672,12 @@ void Connection::process(const Caller_t &caller,
string btAddr = id->second.substr(0,
id->second.find("+"));
BOOST_FOREACH(const
SyncConfig::ConfigList::value_type &server,
servers) {
- SyncContext context(server.first);
- string url = context.getSyncURL();
- SE_LOG_INFO (NULL, NULL, "matching against
%s",url.c_str());
+ SyncConfig config(server.first);
+ string url = config.getSyncURL();
+ SE_LOG_DEBUG(NULL, NULL, "matching against
%s",url.c_str());
+ // this will not match:
+ // syncURL = obex-bt://mac-address,
http://some.ip.address:port
+ // syncURL = http://mac-address+channel
if (url.find ("obex-bt://") ==0 &&
url.substr(strlen("obex-bt://"), url.npos) == btAddr) {
config = server.first;
break;
diff --git a/src/syncevo/SyncConfig.cpp b/src/syncevo/SyncConfig.cpp
index 9c3a795..342056b 100644
--- a/src/syncevo/SyncConfig.cpp
+++ b/src/syncevo/SyncConfig.cpp
@@ -386,23 +386,33 @@ SyncConfig::TemplateList
SyncConfig::getBuiltInTemplates()
result.addDefaultTemplate("Google", "http://m.google.com/sync");
result.addDefaultTemplate("ZYB", "http://www.zyb.com");
result.addDefaultTemplate("Mobical", "http://www.mobical.net");
+ // Why is this called SyncEvolution*Client*?
+ // It is the config for a SyncEvolution server and thus should be
+ // name "SyncEvolution" to be consistent with the other template names.
result.addDefaultTemplate("SyncEvolutionClient",
"http://www.syncevolution.org");
result.sort (TemplateDescription::compare_op);
return result;
}
-SyncConfig::TemplateList SyncConfig::matchPeerTemplates(const DeviceList
&peers)
+static string SyncEvolutionTemplateDir()
{
- TemplateList result;
- // match against all possible templates without any assumption on
directory
- // layout, the match is entirely based on the metadata .template.ini
string templateDir(TEMPLATE_DIR);
const char *envvar = getenv("SYNCEVOLUTION_TEMPLATE_DIR");
if (envvar) {
templateDir = envvar;
}
+ return templateDir;
+}
+
+SyncConfig::TemplateList SyncConfig::matchPeerTemplates(const DeviceList
&peers)
+{
+ TemplateList result;
+ // match against all possible templates without any assumption on
directory
+ // layout, the match is entirely based on the metadata .template.ini
+ string templateDir(SyncEvolutionTemplateDir());
+
std::queue <std::string, std::list<std::string> > directories;
if (isDir(templateDir)) {
directories.push (templateDir);
@@ -447,11 +457,7 @@ boost::shared_ptr<SyncConfig>
SyncConfig::createPeerTemplate(const string &serve
}
// case insensitive search for read-only file template config
- string templateConfig(TEMPLATE_DIR);
- const char *envvar = getenv("SYNCEVOLUTION_TEMPLATE_DIR");
- if (envvar) {
- templateConfig = envvar;
- }
+ string templateConfig(SyncEvolutionTemplateDir());
// before starting another fuzzy match process, first try to load the
// template directly taking the parameter as the path
@@ -683,7 +689,8 @@ boost::shared_ptr<SyncConfig>
SyncConfig::createPeerTemplate(const string &serve
} else if (boost::iequals(server, "syncevolutionclient")) {
config->setSyncURL("http://yourserver:port");
config->setWebURL("http://www.syncevolution.org");
- config->setConsumerReady(true);
+ // No normal consumer will run a SyncEvolution HTTP server.
+ // config->setConsumerReady(true);
source = config->getSyncSourceConfig("addressbook");
source->setURI("addressbook");
source = config->getSyncSourceConfig("calendar");
@@ -1997,7 +2004,7 @@ int TemplateConfig::serverModeMatch
(SyncConfig::MatchMode mode)
return BEST_MATCH;
}
-/*
+/**
* fingerprint = Manufacture_Mod
* Mod = ModPre([a-z]*)ModMid([0-9]*)ModLast([a-z]*)
* 7210c = "" 7210 c
diff --git a/src/syncevo/SyncConfig.h b/src/syncevo/SyncConfig.h
index 9af8742..fb23b67 100644
--- a/src/syncevo/SyncConfig.h
+++ b/src/syncevo/SyncConfig.h
@@ -1588,9 +1588,11 @@ class PersistentSyncSourceConfig : public
SyncSourceConfig {
virtual const char* getSupportedTypes() const { return ""; }
};
-/*
+/**
* Representing a template configuration node
- * */
+ *
+ * PO: what is a template configuration node?
+ */
class TemplateConfig
{
boost::shared_ptr<FileConfigNode> m_metaNode;
--
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:20 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #19 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-15 00:20:05 PST
---
(In reply to comment #18)
> With this assumption, I compromised a little to make the
finger(print) string
> more technical to help a better match, with this approach:
> Nokia_N7210 will never match to LG_N7210c;
Not at all? What if Company Foo and Bar both sell the identical device XYZ and
we only have a template for Foo_XYZ?
I was inaccurate. It will show up with a low
matching level so that users can
select it by themselves via UI. Eventualy, we will update the fingerprint for
Foo_XYZ to also cover Bar_XYZ.
> Nokia_N700 match with Nokia_N7000 will have less score than
Nokia_N700 match
> with Nokia_N701
> I consider these features useful.
I have no idea how well this matching will work in practice.
Some real examples:
./syncevolution --template ?Nokia_N7210c
Available configuration templates:
Nokia_7210c = Nokia 7210c phone 4
Nokia = Default templates for nokia phone 2
ServerDefault = server side default template 1
SyncEvolutionServer = SyncEvolution server side template 1
./syncevolution --template ?7210c
Available configuration templates:
Nokia = Default templates for nokia phone 1
Nokia_7210c = Nokia 7210c phone 1
ServerDefault = server side default template 1
SyncEvolutionServer = SyncEvolution server side template 1
IMHO the Nokia_7210c template should get a higher score in the
second case.
I thought about this before, it was because "7210c" is
ambiguous to the
matching, I took this as manufacture field by default. If you don't know the
manufacture, you can use
./syncevolution -l \?_7210c
Available configuration templates:
Nokia_7210c = Nokia 7210c phone 4
Funambol = http://my.funambol.com 2
Nokia = Default templates for nokia phone 2
ScheduleWorld = http://sync.scheduleworld.com 2
ServerDefault = server side default template 2
SyncEvolutionServer = SyncEvolution server side template 2
Overall the whole matching code seems way to complicated to me. A
"longest
common subsequence" match and a score defined as "length of
subsequence"/"length of fingerprint in template" might provide more
intuitive
results. I have an implementation of LCS lying around somewhere. Ping me if you
want it.
You might be right.. LCS might be a good simple matching while this
complicated
solution provides improvement possibilities. There are several parameters you
can tune with to come out with a better matching if we later found useful.
Congwu, can you add the real templates together with
this patch and add unit tests for the code to the Cmdline tests?
What do you mean
"real templates" here? Why do I need to add them?
I agree most except blow:
How can we match with HTTP based SyncURLs? Is http://mac-address+channel has
any meaning? How can we match the mac address against an ip address for this
case: http://some.ip.address:port
Regarding the code, here's a diff for changes that I would find useful:
+ // this will not match:
+ // syncURL = obex-bt://mac-address,
http://some.ip.address:port
+ // syncURL = http://mac-address+channel
if (url.find
("obex-bt://") ==0 &&
url.substr(strlen("obex-bt://"), url.npos) == btAddr) {
config = server.first;
break;
--
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:52 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #20 from pohly <patrick.ohly(a)intel.com> 2010-01-15 01:52:02 PST ---
(In reply to comment #19)
(In reply to comment #18)
> > With this assumption, I compromised a little to make the finger(print) string
> > more technical to help a better match, with this approach:
> > Nokia_N7210 will never match to LG_N7210c;
>
> Not at all? What if Company Foo and Bar both sell the identical device XYZ and
> we only have a template for Foo_XYZ?
I was inaccurate. It will show up with a low matching level so that users can
select it by themselves via UI. Eventualy, we will update the fingerprint for
Foo_XYZ to also cover Bar_XYZ.
You are very optimistic about our abilities to keep the database updated ;-)
I'm a bit more pessimistic, based on my experience with maintaining a similar
database of CD writers in MakeCD. I therefore think that the code should
provide a better score for Bar_XYZ already when only Foo_XYZ is listed.
> IMHO the Nokia_7210c template should get a higher score in the
> second case.
I thought about this before, it was because "7210c" is ambiguous to the
matching, I took this as manufacture field by default.
If you don't know the
manufacture, you can use
./syncevolution -l \?_7210c
I think the code should handle this, not the user.
> Overall the whole matching code seems way to complicated to me.
A "longest
> common subsequence" match and a score defined as "length of
> subsequence"/"length of fingerprint in template" might provide more
intuitive
> results. I have an implementation of LCS lying around somewhere. Ping me if you
> want it.
You might be right.. LCS might be a good simple matching while this complicated
solution provides improvement possibilities.
Where do you see an advantage of the "intelligent" matching compared to a
"dumb" LCS? Perhaps we can do some thought experiments to compare the two
approaches without actually implementing them.
> Congwu, can you add the real templates together with
> this patch and add unit tests for the code to the Cmdline tests?
What do you mean "real templates" here? Why do I need to add them?
I mean the src/templates that were in a later patch. Add them in the same patch
that also adds the code and you can implement unit testing also in that patch.
I agree most except blow:
How can we match with HTTP based SyncURLs?
We can't. My point was that we wanted to turn syncURL into a list of urls for
peers which can be contacted via different transports. This new code should
cope with such a config by extracting the obex+bt:// urls and comparing against
those. Probably we need some general-purpose utility code in SyncConfig to
return "syncURL" not as a plain string, but a list of urls.
--
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 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #21 from pohly <patrick.ohly(a)intel.com> 2010-01-15 01:53:11 PST ---
The LCS code can be found in bug #2432.
--
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:28 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #22 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-17 20:28:43 PST
---
(In reply to comment #20)
(In reply to comment #19)
Where do you see an advantage of the "intelligent" matching compared to a
"dumb" LCS? Perhaps we can do some thought experiments to compare the two
approaches without actually implementing them.
> > Congwu, can you add the real templates together with
> > this patch and add unit tests for the code to the Cmdline tests?
> What do you mean "real templates" here? Why do I need to add them?
Ok, I updated the code using your LCS based matching (I fixed some minor
problem in your code so Patrick please double check).
I would summarize previous discussions as below:
Man_Mod based matching:
The input string has a pre-defined format, the matching code is a little
complex not straightforward to understand.
The good point might be: the search might works better: we can give a higher
weight in the Manufacture matching part(because phones from the same
manufacture tend to have more configurations in common, if the manufacture does
not match exactly, we will better consider this as not match); in the model
matching part, this part is based on fuzzy match, however if there is digits
within the string, we will not do character based matching but convert them to
numbers and compare the difference).
LCS based matching:
The input string can be any, the matching is based on well known LCS algorithm
so is easier to understand. It works good enough at this moment.
I mean the src/templates that were in a later patch. Add them in the
same patch
that also adds the code and you can implement unit testing also in that patch.
I
squashed these patches into one.
> I agree most except blow:
> How can we match with HTTP based SyncURLs?
We can't. My point was that we wanted to turn syncURL into a list of urls for
peers which can be contacted via different transports. This new code should
cope with such a config by extracting the obex+bt:// urls and comparing against
those. Probably we need some general-purpose utility code in SyncConfig to
return "syncURL" not as a plain string, but a list of urls.
I see, almost
forgot this.. I mark this as TODO because I am not sure how to
define the active transport if there is more than one listed? I remember there
was discussions about this, you mentioned this should be handled by the code.
We can do this if the user only have one transport library available. If both
HTTP/BLUETOOTH transport is aviable and the user specified both a HTTP based
URL and a Bluetooth based URL, which one should we pick up during
createTransportAgent()? We may fall back to pick up the first URL appeared. Do
you agree?
--
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:41 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #23 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-17 20:41:07 PST
---
Another point forgot to mention: the cmd line --template \?[device]
implementation changed a little so that when device is not null, I will match
against *only* templates for SyncML server mode. I got stuck here: If matching
all templates, the templates for built-in servers (Funambol, Scheduleworld)
will be inevitably listed (They must be visible to the template matching
process because we might need to load them for thumbnails). We can further
improve this by changing the cmd line to let the user tell us which mode he
wants match exactly (For a SyncML client or For a SyncML server).
This works well at this moment, later if we start adding peer templates at the
client mode, it need revisiting.
--
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:28 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #24 from pohly <patrick.ohly(a)intel.com> 2010-01-18 01:28:18 PST ---
(In reply to comment #22)
Ok, I updated the code using your LCS based matching (I fixed some
minor
problem in your code so Patrick please double check).
Can you add my code verbatim to util.h/cpp, then fix it? That way it'll be
easier to review for me (and my mistakes will be exposed mercilessly, as they
deserve! ;-)
Please do this in separate commits, not roled into the "Configuration templates
matching" patch.
LCS based matching:
The input string can be any, the matching is based on well known LCS algorithm
so is easier to understand. It works good enough at this moment.
Another point in favor of LCS: when we look at a Bluetooth device name, we
cannot assume that it has any kind of format and thus need a fuzzy matching. I
know from some real-world examples that it is more like that people use
"<person> <model>" rather than "<manufacturer>
<model>".
> > I agree most except blow:
> > How can we match with HTTP based SyncURLs?
>
> We can't. My point was that we wanted to turn syncURL into a list of urls for
> peers which can be contacted via different transports. This new code should
> cope with such a config by extracting the obex+bt:// urls and comparing against
> those. Probably we need some general-purpose utility code in SyncConfig to
> return "syncURL" not as a plain string, but a list of urls.
I see, almost forgot this.. I mark this as TODO because I am not sure how to
define the active transport if there is more than one listed? I remember there
was discussions about this, you mentioned this should be handled by the code.
We can do this if the user only have one transport library available. If both
HTTP/BLUETOOTH transport is aviable and the user specified both a HTTP based
URL and a Bluetooth based URL, which one should we pick up during
createTransportAgent()? We may fall back to pick up the first URL appeared. Do
you agree?
This is a different problem. Basically we would have to look at which transport
is currently available and then try first one, then the other.
Coming back to the current code: event if we assume that syncURL is only
single-value, the code still fails for syncURL=obex-bt://<mac>:<channel>.
if (url.find ("obex-bt://") ==0 &&
url.substr(strlen("obex-bt://"), url.npos)
== btAddr) {
url.substr() will evaluate to <mac>:<channel>, which is != btAddr ==
<mac>.
--
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:33 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #25 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-18 23:33:32 PST
---
(In reply to comment #24)
(In reply to comment #22)
> Ok, I updated the code using your LCS based matching (I fixed some minor
> problem in your code so Patrick please double check).
Can you add my code verbatim to util.h/cpp, then fix it? That way it'll be
easier to review for me (and my mistakes will be exposed mercilessly, as they
deserve! ;-)
Please do this in separate commits, not roled into the "Configuration
Ok,
done.
This is a different problem. Basically we would have to look at which transport
is currently available and then try first one, then the other.
Coming back to the current code: event if we assume that syncURL is only
single-value, the code still fails for syncURL=obex-bt://<mac>:<channel>.
if (url.find ("obex-bt://") ==0 &&
url.substr(strlen("obex-bt://"), url.npos)
== btAddr) {
url.substr() will evaluate to <mac>:<channel>, which is != btAddr ==
<mac>.
I think I already fixed this in that commit:
+ url = url.substr (0, url.find("+"));
I will first truncate the url to remove any '+' postfix.
--
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:08 a.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #26 from pohly <patrick.ohly(a)intel.com> 2010-01-19 09:08:34 PST ---
I have merged this, with some changes:
- reordered patches so that LCS code is added first
(the matching wouldn't have compiled otherwise because there was a reference
to an LCS type)
- moved LCS code into its own src/syncevo/lcs.h because it is sufficiently
large and other users of util.h shouldn't have to parse it
- added lcs.cpp with a unit test based on the original main() function for
file comparison
- for it to pass, merged your fixes into that patch
- used resize() instead of reserve(); shorter and perhaps faster than the
push_back
- instead of building a sequence of characters plus zero cost,
I added an LCS::accessor_sequence which provides a constant
cost function and can read from a normal sequence (std::string
in the matching)
- replaced "super" source name with "calendar+todo", because
"super"
is a term about how this is implemented, not something that a user
will understand; the sync-UI special-cases the "calendar+todo" name
to localize it (like it does for the other standard names)
In your code, "client-test SyncEvo::CmdlineTest::testMatchTemplate" does not
always pass because without "make install" the templates are not found.
As soon as templates get added, the test would have to be updated.
I solved this by adding the current set of templates to the test files which
need to be copied into "testcases".
I have some more questions: do we really want to use .template.ini (hidden)
instead of template.ini? This makes working with the templates harder without
an apparent advantage.
Should the default Nokia template really use the default values? Using
something as for the 7120c might be more suitable.
--
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:41 a.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #27 from pohly <patrick.ohly(a)intel.com> 2010-01-19 10:41:54 PST ---
(In reply to comment #26)
In your code, "client-test
SyncEvo::CmdlineTest::testMatchTemplate" does not
always pass because without "make install" the templates are not found.
As soon as templates get added, the test would have to be updated.
I solved this by adding the current set of templates to the test files which
need to be copied into "testcases".
I noticed that you had also created copies of the current templates under
"test/templates", but I don't see where these files are used. Or did break
the
merging?
Can we remove these duplicate templates? I'd prefer to avoid duplication,
even if that means that the testcases have to be updated when updating the
real 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.
3:54 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #28 from Chen Congwu <congwu.chen(a)intel.com> 2010-01-19 20:54:34 PST
---
(In reply to comment #26)
I have some more questions: do we really want to use .template.ini (hidden)
instead of template.ini? This makes working with the templates harder without
an apparent advantage.
That was the original proposal. Thinking again, I can not
see any benefits
either because we may allow user edit the file directly since we are using a
fault tolerant LCS matching...
Should the default Nokia template really use the default values?
Using
something as for the 7120c might be more suitable.
At this moment (and possibly
SyncEvolution 1.0) release, this is the right
solution I think. When we start enabling more and more phones, we might found
another phone model is more appropriate for this job.
(In reply to comment #27)
(In reply to comment #26)
> In your code, "client-test SyncEvo::CmdlineTest::testMatchTemplate" does
not
> always pass because without "make install" the templates are not found.
> As soon as templates get added, the test would have to be updated.
>
> I solved this by adding the current set of templates to the test files which
> need to be copied into "testcases".
I noticed that you had also created copies of the current templates under
"test/templates", but I don't see where these files are used. Or did break
the
merging?
Can we remove these duplicate templates? I'd prefer to avoid duplication,
even if that means that the testcases have to be updated when updating the
real templates.
Yes. So you prefer to test with the real templates? I thought we
can conduct
the unit tests with an older and stable version of templates, so that we don't
have to update the testcases from time to time; the list of devices may evolves
larger and lager when we add more real templates into our system.
I updated these and pushed to configuration-template branch, also fixed a link
failure.
--
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:17 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|major |normal
--- Comment #29 from pohly <patrick.ohly(a)intel.com> 2010-01-21 00:17:53 PST ---
(In reply to comment #28)
> Can we remove these duplicate templates? I'd prefer to avoid
duplication,
> even if that means that the testcases have to be updated when updating the
> real templates.
Yes. So you prefer to test with the real templates? I thought we can conduct
the unit tests with an older and stable version of templates, so that we don't
have to update the testcases from time to time; the list of devices may evolves
larger and lager when we add more real templates into our system.
That's why I wrote the rules in src/Makefile which populate the src/testcases
directory so that only the current, known set of template files are copied.
Adding new templates won't affect the testing, only modifying the existing
templates might.
I updated these and pushed to configuration-template branch, also
fixed a link
failure.
Thanks, merged.
Remaining open work: creating a client config on-the-fly when an authorized
client connects to an HTTP server. Lowering impact.
--
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.
9:17 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |9417
--
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:34 a.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
Bug 7838 depends on bug 7089, which changed state.
Bug 7089 Summary: pairing with Bluetooth devices
http://bugzilla.moblin.org/show_bug.cgi?id=7089
What |Old Value |New Value
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--
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.
9:31 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |9907
--
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.
9 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
Bug 7838 depends on bug 9907, which changed state.
Bug 9907 Summary: device-specific rules (Nokia 7120C)
http://bugzilla.moblin.org/show_bug.cgi?id=9907
What |Old Value |New Value
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--
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.
9:04 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
Bug 7838 depends on bug 9907, which changed state.
Bug 9907 Summary: device-specific rules (Nokia 7120C)
http://bugzilla.moblin.org/show_bug.cgi?id=9907
What |Old Value |New Value
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--
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 a.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
Bug 7838 depends on bug 9907, which changed state.
Bug 9907 Summary: device-specific rules (Nokia 7120C)
http://bugzilla.moblin.org/show_bug.cgi?id=9907
What |Old Value |New Value
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--
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:41 a.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |10137
--
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.
9:51 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|10137 |
--
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:13 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #33 from Chen Congwu <congwu.chen(a)intel.com> 2010-04-09 02:13:14 PST
---
(In reply to comment #30)
There is one problem: we don't know the session status from server side, which
means we can't tell whether the session is authenticated failure..
Without this information, we have to be conservative that configurations is
never 'reusable', which might suffer denial of service attack as Patrick
already pointed out.
Is there other solutions from synthesis that we can tell whether a server side
session authenticated failed? Otherwise I would like to keep 'reusable' always
'false' and improve that once bug #7709 got fixed.
Wondering whether such 'special config' is necessary, I think
we can:
1) each time there is a client contacting us with no configuration, create the
configuration automatically with its device ID
2) If synchronization failed with authentication problem, mark the
configuration as re-usable; otherwise just continue smoothly
The 're-usable' configuration can be reused for a later new coming client (just
as the special config) or clean up entirely.
--
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.
9:16 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #34 from pohly <patrick.ohly(a)intel.com> 2010-04-09 04:16:42 PST ---
(In reply to comment #33)
(In reply to comment #30)
There is one problem: we don't know the session status from server side, which
means we can't tell whether the session is authenticated failure..
It should be possible to hook into some of the scripts invoked as part of a
server session and set a global session variable once the client is
authenticated. See "INTEGER delayedabort" in SyncContext.cpp for an example.
--
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:26 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #35 from Chen Congwu <congwu.chen(a)intel.com> 2010-04-13 01:25:59 PST
---
Patch in mb7838 (Requires another patch in libsynthesis)
I am OK with adding 'reusale' property in the configuration, if no objection I
will further adapt the test cases for that.
One problem in checkForLoginSuccess(), I have to call it repeatedly inside
Session Step loop because If I tested it and the end of the session, the script
context already gone..
--
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.
9:56 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #36 from pohly <patrick.ohly(a)intel.com> 2010-04-13 04:56:51 PST ---
(In reply to comment #35)
Patch in mb7838 (Requires another patch in libsynthesis)
I need a user-level documentation for this new feature before I can do the
final review and merge. This can be either a README or an addendum (marked as
experimental) to the http://syncevolution.org/development/http-server-howto
Key point that I haven't seen discussed is:
- How does the user set up a server so that it
can create new configs correctly? In particular,
which username/password is expected by the server?
- What is the naming of the new configs?
I am OK with adding 'reusale' property in the configuration,
if no objection I
will further adapt the test cases for that.
I'm not sure yet whether we need the property. Can't we just define that
configuration "temporary-config" is "reusable"?
One problem in checkForLoginSuccess(), I have to call it repeatedly
inside
Session Step loop because If I tested it and the end of the session, the script
context already gone..
We are almost done with 1.0. Instead of merging features that few users will
need, I'd rather refine this. Perhaps in 1.1 we'll have server-side status
codes and then don't need hacks.
--
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:40 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #37 from Chen Congwu <congwu.chen(a)intel.com> 2010-04-13 19:40:40 PST
---
(In reply to comment #36)
(In reply to comment #35)
> Patch in mb7838 (Requires another patch in libsynthesis)
I need a user-level documentation for this new feature before I can do the
final review and merge. This can be either a README or an addendum (marked as
experimental) to the http://syncevolution.org/development/http-server-howto
Let's finalize that here before I update it in the doc.
Key point that I haven't seen discussed is:
- How does the user set up a server so that it
can create new configs correctly? In particular,
which username/password is expected by the server?
Using 'SyncEvolution
Client' template is enough (of source syncURL should set
correctly), username/password was already inside the template.
- What is the naming of the new configs?
The name is
'deviceID-time', any better ideas?
> I am OK with adding 'reusale' property in the
configuration, if no objection I
> will further adapt the test cases for that.
I'm not sure yet whether we need the property. Can't we just define that
configuration "temporary-config" is "reusable"?
That can work
if we hook at the end of the first successful session, at which
point we have to rename the config from 'temporary-config' to a permanent
config for that peer 'deviceID-time'
It works but I think renaming a configuration is a bit confusing.
> One problem in checkForLoginSuccess(), I have to call it
repeatedly inside
> Session Step loop because If I tested it and the end of the session, the script
> context already gone..
We are almost done with 1.0. Instead of merging features that few users will
need, I'd rather refine this. Perhaps in 1.1 we'll have server-side status
codes and then don't need hacks.
Alright, let's go with the older solution
that always create new configs for
any new coming client.
--
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:53 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #38 from pohly <patrick.ohly(a)intel.com> 2010-04-13 23:53:24 PST ---
(In reply to comment #37)
(In reply to comment #36)
> (In reply to comment #35)
> Key point that I haven't seen discussed is:
> - How does the user set up a server so that it
> can create new configs correctly? In particular,
> which username/password is expected by the server?
Using 'SyncEvolution Client' template is enough (of source syncURL should set
correctly), username/password was already inside the template.
In other words, the whole world knows the credentials which are necessary to
connect to my machine, create a config and access my data, and that as soon as
I start syncevo-http-server. This is not secure ;-)
I see several solutions:
1. Add username/password as command line options to syncevo-http-server,
communicate them to syncevo-dbus-server when a new request comes in,
using new keys in the meta information. syncevo-dbus-server then
uses those credentials.
2. We add new config properties, to be set inside
~/.config/syncevolution/config.ini, which specify the default
credentials.
In both cases creating new configs is disabled if no credentials are set.
Solution 1 has the advantage that this feature is discoverable by users of
syncevo-http-server and can be set on a case-by-case basis (run daemon with
specific credentials, connect with new client, restart daemon without
credentials or different ones for a different client).
Solution 2 has the advantage that it can (and should) reuse the secure password
storage features of syncevo-dbus-server.
I tend to prefer solution 1, although it might be worth asking on the mailing
list.
> - What is the naming of the new configs?
The name is 'deviceID-time', any better ideas?
Can we compose the name from manufacturer + model? That may only work after
completing the sync and thus would depend on renaming the config.
> I'm not sure yet whether we need the property. Can't we
just define that
> configuration "temporary-config" is "reusable"?
That can work if we hook at the end of the first successful session, at which
point we have to rename the config from 'temporary-config' to a permanent
config for that peer 'deviceID-time'
It works but I think renaming a configuration is a bit confusing.
Why? Because the user sees a "temporary-config"?
--
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:33 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #39 from Chen Congwu <congwu.chen(a)intel.com> 2010-04-14 00:33:20 PST
---
(In reply to comment #38)
(In reply to comment #37)
> (In reply to comment #36)
> > (In reply to comment #35)
> > Key point that I haven't seen discussed is:
> > - How does the user set up a server so that it
> > can create new configs correctly? In particular,
> > which username/password is expected by the server?
> Using 'SyncEvolution Client' template is enough (of source syncURL should
set
> correctly), username/password was already inside the template.
In other words, the whole world knows the credentials which are necessary to
connect to my machine, create a config and access my data, and that as soon as
I start syncevo-http-server. This is not secure ;-)
Ah, good catch!
I see several solutions:
1. Add username/password as command line options to syncevo-http-server,
communicate them to syncevo-dbus-server when a new request comes in,
using new keys in the meta information. syncevo-dbus-server then
uses those credentials.
2. We add new config properties, to be set inside
~/.config/syncevolution/config.ini, which specify the default
credentials.
In both cases creating new configs is disabled if no credentials are set.
Solution 1 has the advantage that this feature is discoverable by users of
syncevo-http-server and can be set on a case-by-case basis (run daemon with
specific credentials, connect with new client, restart daemon without
credentials or different ones for a different client).
Solution 2 has the advantage that it can (and should) reuse the secure password
storage features of syncevo-dbus-server.
I tend to prefer solution 1, although it might be worth asking on the mailing
list.
I like solution 1 too, such credential is part of HTTP server I think.
> > - What is the naming of the new configs?
> The name is 'deviceID-time', any better ideas?
Can we compose the name from manufacturer + model? That may only work after
completing the sync and thus would depend on renaming the config.
That still may
not be unique, so we still have to append some string to make it
unique.. I think the real problem is we should found a way to notify the user
we have created a configuration named xxx for the client, so that he
understands the configuration name.
> > I'm not sure yet whether we need the property.
Can't we just define that
> > configuration "temporary-config" is "reusable"?
> That can work if we hook at the end of the first successful session, at which
> point we have to rename the config from 'temporary-config' to a permanent
> config for that peer 'deviceID-time'
> It works but I think renaming a configuration is a bit confusing.
Why? Because the user sees a "temporary-config"?
Exactly, that's
really confuse when I sync with the same client, the first time
server said 'temporary-config', later some other name. If there is a UI depicts
profile information about such sync, the sync history would also be confusing..
--
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:57 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #40 from Chen Congwu <congwu.chen(a)intel.com> 2010-04-15 01:57:23 PST
---
(In reply to comment #39)
> I tend to prefer solution 1, although it might be worth asking
on the mailing
> list.
I like solution 1 too, such credential is part of HTTP server I think.
This is implemented.
> > > - What is the naming of the new configs?
> > The name is 'deviceID-time', any better ideas?
>
> Can we compose the name from manufacturer + model? That may only work after
> completing the sync and thus would depend on renaming the config.
That still may not be unique, so we still have to append some string to make it
unique.. I think the real problem is we should found a way to notify the user
we have created a configuration named xxx for the client, so that he
understands the configuration name.
This is still open. Any comments?
--
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:32 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #41 from pohly <patrick.ohly(a)intel.com> 2010-04-15 02:32:40 PST ---
(In reply to comment #40)
(In reply to comment #39)
> > I tend to prefer solution 1, although it might be worth asking on the mailing
> > list.
> I like solution 1 too, such credential is part of HTTP server I think.
This is implemented.
Comments on the patch, please update:
-usage = """usage: %prog http://localhost:<port>/<path>
+usage = """usage: %prog http://localhost:<port>/<path -u
username -p
password>
Note that the options were inserted inside <path>. Besides, they shouldn't be
listed here. The Python modules does that for us. Please use
usage: %prog <options> http://localhost:<port>/<path>
The documentation for the new options also needs a clarification:
help = "The user name accepted by the server"
should become:
help = "The user name checked by by the server when an unknown client
connects. Only if the client provides the right credentials, will a new
configuration be created for it automatically, using these credentials."
> > > > - What is the naming of the new configs?
> > > The name is 'deviceID-time', any better ideas?
> >
> > Can we compose the name from manufacturer + model? That may only work after
> > completing the sync and thus would depend on renaming the config.
> That still may not be unique, so we still have to append some string to make it
> unique.. I think the real problem is we should found a way to notify the user
> we have created a configuration named xxx for the client, so that he
> understands the configuration name.
This is still open. Any comments?
We cannot notify the client. Printing a message to the screen in
syncevo-dbus-server or writing into a log also doesn't help much. Therefore I
think we need meaningful names so that a server user can list configs and
recognize which ones where created for him for which device.
I agree that renaming the config has issues, but it seems to me to be the least
evil one. Perhaps we can also rename the logdir used by the initial successful
session at the end of the session? Note that the Synthesis engine should better
be shut down at that point, because it would continue using the old log dir
path.
--
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:50 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #42 from Chen Congwu <congwu.chen(a)intel.com> 2010-04-15 02:50:40 PST
---
(In reply to comment #41)
> > > > > - What is the naming of the new configs?
> > > > The name is 'deviceID-time', any better ideas?
> > >
> > > Can we compose the name from manufacturer + model? That may only work
after
> > > completing the sync and thus would depend on renaming the config.
> > That still may not be unique, so we still have to append some string to make
it
> > unique.. I think the real problem is we should found a way to notify the user
> > we have created a configuration named xxx for the client, so that he
> > understands the configuration name.
> This is still open. Any comments?
We cannot notify the client. Printing a message to the screen in
syncevo-dbus-server or writing into a log also doesn't help much. Therefore I
think we need meaningful names so that a server user can list configs and
recognize which ones where created for him for which device.
I agree that renaming the config has issues, but it seems to me to be the least
evil one. Perhaps we can also rename the logdir used by the initial successful
session at the end of the session? Note that the Synthesis engine should better
be shut down at that point, because it would continue using the old log dir
path.
Depending on extract information from DevInf looks to me not work well:
1) Will the peer always send its DevInf?
2) Will the DevInf be meaningful? For example, we have seen Nokia N900 as
'Nokia Nxx', that seems to me not make sense.
I still think we need to find other ways to notify the client..
--
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.
9:22 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #43 from pohly <patrick.ohly(a)intel.com> 2010-04-15 04:22:04 PST ---
(In reply to comment #42)
[naming of config based on DevInf]
Depending on extract information from DevInf looks to me not work
well:
1) Will the peer always send its DevInf?
If not, Synthesis will request it. That's why I said that the information
should be available after a sync, but cannot necessarily be extracted from the
first message.
Of course, there will be clients which have no DevInf at all (which I find
unlikely) or no useful information inside.
2) Will the DevInf be meaningful? For example, we have seen Nokia
N900 as
'Nokia Nxx', that seems to me not make sense.
I still think we need to find other ways to notify the client..
Suggestions welcome, 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.
11 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
pohly <patrick.ohly(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|*Feature Request |SyncEvolution
AssignedTo|congwu.chen(a)intel.com |patrick.ohly(a)intel.com
QAContact| |yanshuang.zheng(a)intel.com
--- Comment #44 from pohly <patrick.ohly(a)intel.com> 2010-04-15 06:00:35 PST ---
Replacing the "*Feature Request" to keep this issue out of the queue of issues
ready to be 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.
2:49 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
Chen Congwu <congwu.chen(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|SyncEvolution |*Feature Request
AssignedTo|patrick.ohly(a)intel.com |congwu.chen(a)intel.com
QAContact|yanshuang.zheng(a)intel.com |
--- Comment #45 from Chen Congwu <congwu.chen(a)intel.com> 2010-04-15 21:48:56 PST
---
(In reply to comment #43)
(In reply to comment #42)
[naming of config based on DevInf]
> Depending on extract information from DevInf looks to me not work well:
> 1) Will the peer always send its DevInf?
If not, Synthesis will request it. That's why I said that the information
should be available after a sync, but cannot necessarily be extracted from the
first message.
Of course, there will be clients which have no DevInf at all (which I find
unlikely) or no useful information inside.
> 2) Will the DevInf be meaningful? For example, we have seen Nokia N900 as
> 'Nokia Nxx', that seems to me not make sense.
> I still think we need to find other ways to notify the client..
Suggestions welcome, of course.
Since I don't think we can figure out that automatically, we still need some
user intervention, isn't it?
Extracting information from DevInf might also needs same tricks/hacks as I
already had with 'Authentication failure detection' patch which was not nice.
Can we ask the user provide this information when he starts the sync? For
example, can we reuse 'deviceID' for that purpose? Or some other field in
SyncML?
--
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:03 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
Chen Congwu <congwu.chen(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|*Feature Request |SyncEvolution
AssignedTo|congwu.chen(a)intel.com |patrick.ohly(a)intel.com
QAContact| |yanshuang.zheng(a)intel.com
--- Comment #46 from Chen Congwu <congwu.chen(a)intel.com> 2010-04-15 22:03:30 PST
---
Reset status in comment #44
--
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:40 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
--- Comment #47 from Chen Congwu <congwu.chen(a)intel.com> 2010-04-18 23:39:55 PST
---
(In reply to comment #45)
> > 2) Will the DevInf be meaningful? For example, we have seen
Nokia N900 as
> > 'Nokia Nxx', that seems to me not make sense.
> > I still think we need to find other ways to notify the client..
>
> Suggestions welcome, of course.
Since I don't think we can figure out that automatically, we still need some
user intervention, isn't it?
Extracting information from DevInf might also needs same tricks/hacks as I
already had with 'Authentication failure detection' patch which was not nice.
No, there is a callback in Synthesis DBPlugin API. However I still don't think
such sometimes works, sometimes not works approach as a solution.
Current patch does the following:
1) Add 'serverConfig' property shared by peers inside the same context, the
value depicts a configuration that will be used for new coming clients, empty
if none exits.
2) When a new clients comes, if 'serverConfig' is not empty, reuse the
configuration defined by it's value; otherwise create the configuration
automatically using (removeDeivceID and time as the name) and recored the name
inside 'serverConfig'
3) When a session (with name equals the value inside 'serverConfig') got a
session without authentication error, set the value in 'serverConfig' as empty.
The remaining problem is such newly created configuration name is not
meaningful, but since we don't have a good solution so far, I would like to
take that as an enhancement that later we can work on.
--
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:40 p.m.
New subject: [Bug 7838] creating client configurations
http://bugzilla.moblin.org/show_bug.cgi?id=7838
ZhangJingke <jingke.zhang(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
CC| |jingke.zhang(a)intel.com
Resolution| |MIGRATED
--- Comment #48 from ZhangJingke <jingke.zhang(a)intel.com> 2010-04-26 19:40:09 PST
---
It is moved to http://bugs.meego.com/show_bug.cgi?id=1360
--
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
4699
days old
syncevolution-issues@syncevolution.org
56 comments
1 participants
participants (1)
-
bugzilla＠moblin.org