multiple messages per package support is done with the transmitChunckFunc() callback, which is called by mgrCreateNextCommand() if the encoder failed to build a command because of the lack of space in the workspace. Then, we need to send the beginning of the message, but we can't send all the content of the workspace because it also contains the message we received and that we are processing. Therefore, we need to backup what is left to process and to restore it later. But to do that we need to know the remaining size of the message to backup. In order to do that, I modified the toolkit and added a global variable containing that size. Is there any other way to deal with the mutiple message per package ? Is there something in the toolkit to manage that ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The way I recall it generally being used was to check for available space before attempting to add a command, rather than after. Generally, people kept a fudge factor of the estimated space required to close out all current commands. For example, if you are adding item after item inside a sync command, you want to stop adding items when there is just enough room to close the sync and syncbody block. You do not want to backup the entire sync command, and no matter what, you need to close the syncbody and such. It is also helpful to check at each level - for example, adding an empty sync command, where you don't have any room for items within is rather pointless, better to just skip the entire block (or add an alert 222, if necessary).
dgc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You might want to use the smlStartEvaluation() feature intoduced in the RTK 4.1. It allows you to find how much space you have for additional commands and takes into account that you need to close some tags to complete a message. This was added for SyncML 1.1 <moredata> support, but is very handy also to handle multiple messages in general. See RTK 4.1 docs for details.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
multiple messages per package support is done with the transmitChunckFunc() callback, which is called by mgrCreateNextCommand() if the encoder failed to build a command because of the lack of space in the workspace. Then, we need to send the beginning of the message, but we can't send all the content of the workspace because it also contains the message we received and that we are processing. Therefore, we need to backup what is left to process and to restore it later. But to do that we need to know the remaining size of the message to backup. In order to do that, I modified the toolkit and added a global variable containing that size. Is there any other way to deal with the mutiple message per package ? Is there something in the toolkit to manage that ?
The way I recall it generally being used was to check for available space before attempting to add a command, rather than after. Generally, people kept a fudge factor of the estimated space required to close out all current commands. For example, if you are adding item after item inside a sync command, you want to stop adding items when there is just enough room to close the sync and syncbody block. You do not want to backup the entire sync command, and no matter what, you need to close the syncbody and such. It is also helpful to check at each level - for example, adding an empty sync command, where you don't have any room for items within is rather pointless, better to just skip the entire block (or add an alert 222, if necessary).
dgc
You might want to use the smlStartEvaluation() feature intoduced in the RTK 4.1. It allows you to find how much space you have for additional commands and takes into account that you need to close some tags to complete a message. This was added for SyncML 1.1 <moredata> support, but is very handy also to handle multiple messages in general. See RTK 4.1 docs for details.