For codegen to work well you need a well-defined API set, which doesn?t change. Otherwise each time it changes you?ll have to go change your code generation code. The pre-existing API?s are not so clean, in multiple aspects. It is hard to draw the line between the public functions and the private ones. They are intertwined. The headers IMO messy. This makes it hard to build codegen on top of it.
Those are some of the problems that it addresses. But there is a design aspect too. It is easier to build codegen on a higher level function set. IPCA hides away some of the complexity of callbacks, handles, etc. from the codegen code. Having each layer fix some level of complexity and having layers build on each other (each of which is simpler) leads to a better design and architecture. Thanks, - Omar From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ??? Sent: Tuesday, March 7, 2017 11:01 PM To: Omar Maabreh via iotivity-dev <iotivity-dev at lists.iotivity.org>; Thiago Macieira <thiago.macieira at intel.com>; ??? <glen.kim at samsung.com> Subject: Re: [dev] Smart Home API proposal. Considering frequent adding and changing resource and property in the real world, code generation should be done again and again during developement which lead generated skelton code to be copied and replaced again. Furthermore code generation is a little bit old style I feel. Recently well abstrated API following less user code is more trendy( this comment does not mean Smart Home API.) According to Younggin comment design goal looks different. Whether code generation or not is othogonal from the main idea of his API proposal. Omar could you explain why IPCA is closer to code generation ? BR Uze Choi --------- Original Message --------- Sender : Omar Maabreh via iotivity-dev <iotivity-dev at lists.iotivity.org> Date : 2017-03-08 07:12 (GMT+1) Title : Re: [dev] Smart Home API proposal. Totally agree that code generation is the right solution to this problem which we'd all like to solve. The IPCA api's that are in gerrit right now are a first step in enabling this. Thanks, - Omar -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Thiago Macieira Sent: Tuesday, March 07, 2017 10:06 PM To: iotivity-dev at lists.iotivity.org; glen.kim at samsung.com Subject: Re: [dev] Smart Home API proposal. Em quarta-feira, 8 de mar?o de 2017, ?s 01:31:27 CET, ??? escreveu: > I think making RAML definition is not easy in 3rd party developer's > point of view. they need to know specification to make it again. > therefore, i think this is reasonable proposal which provides API > usability improvement and way to make OCF service and device easily. I don't think the goals are at odds. We do want the easy API. I just don't want *us* to spend time developing it for each and every resource type that OCF comes up with. I'd like us to create a code generator that does that job for us, for current as well as any future resource types. That way, developers won't need to deal with the RAML files or Swagger files. They'll use the generated API. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev [cid:image001.gif at 01D2983D.70E70120] [Image removed by sender.] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170309/7ea7f7fb/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: ~WRD000.jpg URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170309/7ea7f7fb/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13402 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170309/7ea7f7fb/attachment.gif>
