Task #3337
closed
The MetaInfo ContentType should not be restricted
0%
Description
Right now when decoding a data packet, if the MetaInfo content type is not one of the known types from the TLV spec then the library throws an exception. But applications should be able to experiment with content types. So, the library should be changed to allow any content type when decoding.
Updated by Anonymous about 9 years ago
- Description updated (diff)
The plan is to keep an enum for the return value from MetaInfo.getType, and add another enum: APPLICATION. Then add another method: getApplicationContentType which returns the specific code from the wire encoding. This keeps the current API the same and separates recognized content types from unregistered application-specific values.
Updated by Alex Afanasyev about 9 years ago
I don't think I agree with the separation. In my opinion, getType needs to return just a number and a supplementary enum may be used to define a list of known types. Having 2 API functions is confusing and unnecessary.
Updated by Anonymous almost 9 years ago
The supplementary enum would have to be tied to the data packet encoding scheme which is more complicated.
Updated by Anonymous over 8 years ago
- Status changed from New to Closed
Changes merged to master. The MetaInfo CCL API page is updated.