Hi Chen,
I'm not sure I fully understood the scenario - please correct my
assumptions if they are wrong:
I assume you are using the GetSyncMLBuffer/RetSyncMLBuffer API (rather
than the convenience routines ReadSyncMLBuffer/WriteSyncMLBuffer).
The thing I don't understand is the "our parser" part. Which parser
are you referring to? The libsyncml one or libsynthesis one?
In libsynthesis, there's indeed the problem that the parser only reads
up to the end of SyncML, even if you pass it more data with
RetSyncMLBuffer(). And when you use GetSyncMLBuffer for send later,
you'll have the garbage in front of the new message. Is it this
scenario you are looking at?
Anyway, I'll have a look at that problem - I fainly remember having
solved that problem already a while ago for the server or one of our
older pre-libsynthesis builds, and probably it's a small change to
activate that fix for the libsynthesis case.
Best Regards,
Lukas
On Sep 14, 2009, at 12:19 , Chen, Congwu wrote:
Hi, Lukas
While I am testing obex connection with libsyncml, it complains xml
parsing error. After investigation, I found the following issue in
our code:
We are using the same buffer for both input message and output
message. If the previous input message ends with spaces or other
garbage data, this part of garbage data will not be processed by our
parser and will be sent out as output message to the remote. (In the
libsyncml case, additional '\n' was sent before starting of xml
document).
We need to ensure we have fully processed the incoming data. One
possible solution is: during the end tag of "SyncML", scan forward
until end of buffer or another start tag of "SyncML".
Thanks,
Chen,Congwu
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
