On Thu, 2009-11-26 at 10:30 +0000, Chen, Congwu wrote: > >I've looked at the code. Some comments: > > > > Server Alerted Sync: SAN generation > > > > ContentType in the 'Get' command during the SAN should be XML or > >WBXML instead > > of SAN Notification. > > > >Why that? Perhaps I misunderstand the code, but doesn't it ensure that > >the content type for the SAN message is > >TransportAgent::m_contentTypeServerAlertedNotificationDS and *not* XML > >or WBXML? > It means the request sent for SAN must have a san content type but when you > use > "Get" to pull response you must use XML/WBXML. > This is found by Nokia phone and it is reasonable.
Hmm, this (or some of the other changes) breaks "test-dbus.py". In TestConnection.testStartSync a client sends a SyncML message as XML and expects a XML message back, but it gets 'application/vnd.syncml.ds.notification'. [a bit later] No, it's the "if m_serverMode, then generate SAN" part. That check is a bit too simplistic, because server mode might already have been entered via initServer(). That's what syncevo-dbus-server does when it receives a connection from a client together with the first SyncML message. I've changed the if clause to: if (m_serverMode && !m_initialMessage.size()) In other words, a SAN will be generated only if there is no message to process already. Reasonable? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
