[Syncevolution-issues] [Bug 1360] New: creating client configurations

http://bugs.meego.com/show_bug.cgi?id=1360 Summary: creating client configurations Classification: MeeGo Projects Product: SyncEvolution Version: unspecified Platform: Netbook OS/Version: IA Status: ASSIGNED Severity: normal Priority: Medium Component: SyncEvolution AssignedTo: syncevolution-bugs(a)meego.bugs ReportedBy: jingke.zhang(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, syncevolution-default-bugs(a)meego.bugs Estimated Hours: 0.0 This is from http://bugzilla.moblin.org/show_bug.cgi?id=7838 Description From pohly 2009-11-06 03:15:30 PST (-) [reply] 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 ------- Comment #1 From pohly 2009-12-02 06:49:20 PST (-) [reply] ------- (In reply to comment #0) This is true for all transports. That is only true for HTTP. With OBEX, the right client config is found by matching the client's MAC address against the syncURL. That still looks like the right solution for HTTP. For OBEX, simply scanning+pairing provides enough information to set the syncURL correctly. ------- Comment #2 From Chen Congwu 2009-12-14 19:18:30 PST (-) [reply] ------- (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. 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' 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. ------- Comment #3 From pohly 2009-12-15 01:54:52 PST (-) [reply] ------- (In reply to comment #2) It's a bit hard to follow who identifies whom. .. is used by the client to identify the server ... ... used by the server ... 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? '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. 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. 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. ------- Comment #4 From Chen Congwu 2009-12-15 23:38:41 PST (-) [reply] ------- (In reply to comment #3) 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? Yes, the different is configuration in 1b need to be created on the fly while 2b is pre-chosen. I think it's covered by case 1 (Client inited scenario). I see the problem... Yes, agree. ------- Comment #5 From pohly 2009-12-16 00:11:26 PST (-) [reply] ------- (In reply to comment #4) 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. 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. > > 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. 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. ------- Comment #6 From Chen Congwu 2009-12-16 01:00:29 PST (-) [reply] ------- (In reply to comment #5) 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. Looks good. ------- Comment #7 From pohly 2009-12-16 03:22:35 PST (-) [reply] ------- (In reply to comment #6) 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. ------- Comment #8 From Chen Congwu 2009-12-17 17:43:25 PST (-) [reply] ------- (In reply to comment #5) 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. ------- Comment #9 From pohly 2009-12-17 23:13:36 PST (-) [reply] ------- (In reply to comment #8) 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. ------- Comment #10 From Chen Congwu 2009-12-29 23:32:15 PST (-) [reply] ------- (In reply to comment #5) > - 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. Still need to be done. -- Configure bugmail: http://bugs.meego.com/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.