On Tue, 01 Dec 2009, Ohly, Patrick wrote: > 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? Yes, I think you are right > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > >
-- Regards, Chen Congwu Moblin China Development _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
