Task #3337
closed
The MetaInfo ContentType should not be restricted
Added by Anonymous about 9 years ago.
Updated over 8 years ago.
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.
- 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.
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.
The supplementary enum would have to be tied to the data packet encoding scheme which is more complicated.
- Status changed from New to Closed
Changes merged to master. The MetaInfo CCL API page is updated.
Also available in: Atom
PDF
Updated by