I'm not sure I really understand your question, but one does need to realize that this is a toolkit, which requires an application layer above it. Thus the toolkit extracts the data from individual XML elements and presents that data to the application layer. The application layer would then typically be responsible for combining those data pieces into an application layer large data object.
Note that I have not actually used the toolkit large object code myself - perhaps it provides more support than I expect, but I doubt it.
dgc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed, we must implement combining data pieces or splitting large objects at the application layer by ourself. I took a lot of time to understand this point. who can give me sample codes(SyncClient) that support large objects? I don't know how to calculate the size of data piece, because the left part of the message contains many unclosed tags. I also don't know how to avoid more than one command or data object placed in one message.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, several comments here.
1) If you want this thread to be understandable to other people, reply to the most recent message, not the original.
2) I have no idea what you are doing, or where you really are stuck.
Used properly, there won't be any unclosed tags on the incoming data, because you should be looking at fully populated data structures, not the raw XML/WBXML.
Regarding sending more than one data object or command in a message - I don't know what you are talking about - you have to have the header, some status elements, large object elements, and then you close the element/command/message and send the message whenever you want. Avoiding more is trivial - send whatever you put in the outgoing stream.
If you mean calculate what size data to include, take a guess and get things working - what is your current max message size in effect, and then the tags that will need to be closed are straigtforward to calculate, although personally, I'd just guess with a reasonable safety margin, and send a reasonably fixed buffer size.
Beyond that, I would __strongly__ advise reviewing working code, such as Sync4J. There is a LOT more work involved in doing SyncML than people expect. That's why companies have toolkits you can license (not cheap), or there is open source (for non-commercial use, or licensible) available (or contractors available).
dgc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you! I have another question.
Take a look at release readme of toolkit_4_4.
Changes in the Maintenance 4 Release
...
• Implementing new extension for “Large Object Handling”, new API to calculate remaining space for data after setting up the tag-structure skeleton
...
Could you tell me where the new API is?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, I cannot tell you where the new functions are, without actually doing the work that I would expect you to do for yourself. To reiterate - "Note that I have not actually used the toolkit large object code myself".
In particular, I expect people to make a reasonable effort at solving their own problems first, before asking for help. You have found the readme file, you have found Sourceforge. All that remains is to fetch the version of the kit _before_ the comment, and look at the differences. I do not think it very difficult to compare a header file from before the large object changes to a header file from after the large object changes, and see what new functions may have been added, or existing functions changed. Worst case, fetch the entire tree from before and after, and run a full diff (or WinMerge, or whatever). Repeat with older versions until you find what you are looking for.
dgc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you! I have another question.
Take a look at release readme of toolkit_4_4.
Changes in the Maintenance 4 Release
...
• Implementing new extension for “Large Object Handling”, new API to calculate remaining space for data after setting up the tag-structure skeleton
...
Could you tell me where the new API is?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you tell me where the codes check the size of data to support large objects? I found many places, but there seems to be nothing.
I'm not sure I really understand your question, but one does need to realize that this is a toolkit, which requires an application layer above it. Thus the toolkit extracts the data from individual XML elements and presents that data to the application layer. The application layer would then typically be responsible for combining those data pieces into an application layer large data object.
Note that I have not actually used the toolkit large object code myself - perhaps it provides more support than I expect, but I doubt it.
dgc
Thank you for your help.
Indeed, we must implement combining data pieces or splitting large objects at the application layer by ourself. I took a lot of time to understand this point. who can give me sample codes(SyncClient) that support large objects? I don't know how to calculate the size of data piece, because the left part of the message contains many unclosed tags. I also don't know how to avoid more than one command or data object placed in one message.
OK, several comments here.
1) If you want this thread to be understandable to other people, reply to the most recent message, not the original.
2) I have no idea what you are doing, or where you really are stuck.
Used properly, there won't be any unclosed tags on the incoming data, because you should be looking at fully populated data structures, not the raw XML/WBXML.
Regarding sending more than one data object or command in a message - I don't know what you are talking about - you have to have the header, some status elements, large object elements, and then you close the element/command/message and send the message whenever you want. Avoiding more is trivial - send whatever you put in the outgoing stream.
If you mean calculate what size data to include, take a guess and get things working - what is your current max message size in effect, and then the tags that will need to be closed are straigtforward to calculate, although personally, I'd just guess with a reasonable safety margin, and send a reasonably fixed buffer size.
Beyond that, I would __strongly__ advise reviewing working code, such as Sync4J. There is a LOT more work involved in doing SyncML than people expect. That's why companies have toolkits you can license (not cheap), or there is open source (for non-commercial use, or licensible) available (or contractors available).
dgc
Thank you! I have another question.
Take a look at release readme of toolkit_4_4.
Changes in the Maintenance 4 Release
...
• Implementing new extension for “Large Object Handling”, new API to calculate remaining space for data after setting up the tag-structure skeleton
...
Could you tell me where the new API is?
No, I cannot tell you where the new functions are, without actually doing the work that I would expect you to do for yourself. To reiterate - "Note that I have not actually used the toolkit large object code myself".
In particular, I expect people to make a reasonable effort at solving their own problems first, before asking for help. You have found the readme file, you have found Sourceforge. All that remains is to fetch the version of the kit _before_ the comment, and look at the differences. I do not think it very difficult to compare a header file from before the large object changes to a header file from after the large object changes, and see what new functions may have been added, or existing functions changed. Worst case, fetch the entire tree from before and after, and run a full diff (or WinMerge, or whatever). Repeat with older versions until you find what you are looking for.
dgc
I tried, but found nothing about these APIs and little differences. I even doubt it doesn't support protocol 1.1.2. So I have to do it myself.
Thank you very much.
Thank you! I have another question.
Take a look at release readme of toolkit_4_4.
Changes in the Maintenance 4 Release
...
• Implementing new extension for “Large Object Handling”, new API to calculate remaining space for data after setting up the tag-structure skeleton
...
Could you tell me where the new API is?