Hi John/Pat, First of all, the generated source code in Control Manager probably not be changed or extended soon, I believe. Then Let's exclude the Control Manager example from this discussion.
Regardless the acceptance of generated code in Control Manager, What is the criteria of generated code acceptance is not easy question. Let's assume the what could be mostly like to happen next in the IoTivity. When we define the Resource model for specific object, probably specification will be defined by RAML tool and spec.(which is discussed currently). Each Resource Class could will be generated by RAML to C or Java Class tool. This case, RAML converter tool will need to be in the contribution scope. But should this contribution be mandated? In This case, Thiago's question list is helpful to judge it. But, This is open source project then everything need to be done voluntarily. Pat, then what do you expect as next order of business? Your comment: "BTW, the next order of business is dependency handling." I cannot imagine what could it be. BR, Uze Choi -----Original Message----- From: Light, John J [mailto:[email protected]] Sent: Saturday, January 24, 2015 2:37 AM To: Lankswert, Patrick; uzchoi at samsung.com; Macieira, Thiago; iotivity- dev at lists.iotivity.org Subject: RE: [dev] Control Manager Pat, Uze, I am having trouble understanding Uze Choi's comments, so I will suggest interpretations in the hope of coming to a common understanding. I do this in the service of coming to a timely resolution of the issue. "developer can easily extend the other resource model with referencing to generated code" I'm not aware of the Control Manager architecture, but this seems to suggest that the generated code is not expected to change because it provides a framework for other resource code that isn't generated, and the framework itself won't change. "If the code generator make strange code cannot be done by manually, then it is critical but this case is far away from this." This seems to recognize the importance of the code generation issue and suggest that since the generated code isn't likely to need to change, we don't need to worry about the issue for a while. "Aligning to the IoTivity resource architecture is most important consideration factor" This seems to say that the functional aspect of the Control Manager is most important, so issues of "open source correctness" should be considered secondary. I would like to see some quick agreement on what Uze is saying before we make a decision. The sooner that happens, the sooner we can fully discuss the issues. John Light -----Original Message----- From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of Lankswert, Patrick Sent: Friday, January 23, 2015 7:42 AM To: uzchoi at samsung.com; Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Control Manager To all, Vijay and I have talked to the owner regarding the plan for the code generation tool. It is proprietary (not for sale). I do not know if they can freely distribute it in binary form though. Out of respect for the owner, we should assume that their decision to not open the tool is final until notified otherwise. That said, I (and I believe the owners) appreciate everybody's thoughts on the issue. I think that we have a general consensus, but since the control manager falls into the services domain, I want to give time to Uze to form and share his opinion. I would like the plan to be: 1) Early next week, I would like to hear from Uze 2) Put together and publish our collected recommendation 3) Assuming the OSWG does not object, we execute our recommendation by the end of next week. Can we agree on this plan? BTW, I really would like an affirmative agreement of 'yes' or 'It would be better, if...' from the folks in this conversation to date: John, Thiago, Erich, Uze, Felix and anybody who is following: I want to thank everybody for the rapid give and take. BTW, the next order of business is dependency handling. Pat -----Original Message----- From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of ???(Uze Choi) Sent: Thursday, January 22, 2015 8:41 PM To: Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Control Manager Hi All, Here Code issue regarding the Code generator is not so critical I believe. Current Control Manager Code generation mechanism is not so sophisticated that developer can easily extend the other resource model with referencing to generated code. If the code generator make strange code cannot be done by manually, then it is critical but this case is far away from this. Regarding merging into the master, there are some criterias I need to think about. Aligning to the IoTivity resource architecture is most important consideration factor I think. I'll evaluate how to align the IoTivity concept and how to maintain the code then decide to merge into master. BR, Uze Choi -----Original Message----- From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of Thiago Macieira Sent: Friday, January 23, 2015 6:14 AM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Control Manager On Thursday 22 January 2015 10:55:37 Keane, Erich wrote: > I agree with John. If at all possible, #1 would be awesome, and it > would be worth exploring what it would take to make it public/free. > > #2 is definitely something I would be OK with, but if the generated > code isn't very maintainable, we might be better off just scrapping > the code if we can't do #1. > > #3 seems like a non-starter for me. Any open-source project that > starts with "buy a $500 piece of software" isn't very open to me. Oh, that's a good point. Option #3 is a sore, sticking point that our competition will gladly publicise. I had to be exhaustive in the options, but you're right, it's a non-starter. And just to be clear, there's a fourth option, which is not to have the code at all. So another option we need to explore is what the relevance of the code is and what gets impacted if it's not there. I think we need to answer these questions: a) is the generated code readable at all? b) is it possible to maintain the generated code by hand? How much effort? c) what platforms does the generator currently run on? d) how difficult would it be to reimplement the generator in (say) Python? e) does the code need to be generated at all? Like Erich said, we may be better off redoing it by hand, f) what happens to the feature if the generated code isn't present? g) what happens if we don't include the feature? Could it be moved to a separate project, outside of IoTivity? -- 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 _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
