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
[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.
Moblin China Development