On Sun, 2009-09-27 at 09:04 +0100, Zhao, Forrest wrote:
1 If concurrent SyncML requests come from multiple SyncML servers,
should obexd stub initiate multiple connections to syncevolution for
the requests coming from seperate SyncML server? Or obexd should
initiate only one connection with syncevolution and reuse it for the
request from all SyncML servers?
Please initiate multiple connections.
2 When should obexd stub destroy the connection with syncevolution?
Should obexd stub destroy the connection with syncevolution when the
"final" is TRUE in the "Reply" signal of interface
"org/syncevolution.Connection"?
In the normal case, the connection would be destroyed like this:
1. SyncEvolution signals Reply() with final=true
2. obexd calls Connection.Close()
In step 1, data may or may not be included, the API allows both. In
practice, SyncEvolution currently does not send data together with the
"final" flag. The final=true comes with an empty message, which is to be
ignored.
In the abnormal cases, both SyncEvolution (via the Abort signal) and
obexd (via a premature Close() with an error description) can disconnect
prematurely. On both of these cases, the receiving peer is not expected
to do anything further with the connection.
--
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.