On 02/22/2018 12:15 PM, Dave Thaler wrote: > > The API can evolve, just like OCF specs, evolve so there's no fixed > definition per se.
Of course it's not fixed over time, but for any given release there should be a well-known API. Then the next release there will be another well known API, such that we can generate a document which lists the difference between, say, 1.3's API and 1.4's API. What is that definition? It's not what is listed at https://www.iotivity.org/documentation, because some header portions are omitted by the documentation build as they're bracketed in #if sections, even though those portions are enabled by default in a code build. Until very recently, the documentation build expanded no defines at all, now it defines (only) the ones related to deprecation. In particular, security things are left out of the online definition. You get left with questions like - Are these part of the API or not? #ifdef __WITH_TLS__ bool OC_CALL OCRepPayloadSetPropPubDataType(OCRepPayload *payload, const char *name, const OicSecKey_t *value); bool OC_CALL OCRepPayloadSetPropPubDataTypeAsOwner(OCRepPayload *payload, const char *name, const OicSecKey_t *value); bool OC_CALL OCRepPayloadGetPropPubDataType(const OCRepPayload *payload, const char *name, OicSecKey_t *value); #endif Is "it depends on how the stack was compiled" really a good answer? (not to mention that the docs will not list those three at all) _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
