I see your point and I will think more about this. My immediate reaction is: allowing apps to call APIs that were not implemented yet is too dangerous - because they can't test their success code path until they get a proper implementation for that API.
We should definitely try to reduce the number of these conditions though. It is unclear to me if we really need to build IoTivity in so many different ways. Thanks for all your work on API clean-up, Mats! I am very interested in that too, and I will try to help if I can. Dan -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Mats Wichmann Sent: Thursday, April 6, 2017 7:27 AM To: IoTivity Developer List <iotivity-dev at lists.iotivity.org> Subject: [dev] C API: conditional code Some of the code that *is* in the C API is bracketed in conditional compilation. For example, ocpayload.h has: #ifdef __WITH_TLS__ bool OCRepPayloadSetPropPubDataType(OCRepPayload *payload, const char *name, const OicSecKey_t *value); bool OCRepPayloadSetPropPubDataTypeAsOwner(OCRepPayload *payload, const char *name, const OicSecKey_t *value); bool OCRepPayloadGetPropPubDataType(const OCRepPayload *payload, const char *name, OicSecKey_t *value); #endif I'm not really fond of the idea that the API has different components depending on how the stack has been compiled. Do we want to do this? Or is it better to stub out functions if they don't apply - that is, the above three would be present but return some form of "not implemented" error if called? _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&data=02%7C01%7CDaniel.Mihai%40microsoft.com%7Cb5fb460f5d724c30aca008d47cf90d52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636270856497602762&sdata=CO6izD6cn4h3zJ9vO5Gb6gpnjOPkeBr2X24PQOicyFs%3D&reserved=0
