Em quinta-feira, 2 de mar?o de 2017 11:34:08 PST voc? escreveu: > From the viewpoint of a relative outsider, scattering support for a > platform (especially a "minor" one, by which I mean something specific > like Arduino rather than generic target like "windows" or "linux") all > over the codebase seems a Bad Idea anyway. Is it possible to eventually > refactor so that kind of work can happen in a "ports" tree, at which > point you can then keep a distinction between "officially supported" and > "contrib" targets?
For all the other platforms, we did exactly that. And it improved after the Windows port turned up, with the clean-up that went into in order to support Windows. Arduino was a special case from the beginning because it was so limited that the compromises had to happen throughout the code. For example, it did not support threading, so the code never attempted to. Note that this has two important consequences: 1) IoTivity API in Arduino behaves differently than in other platforms, due to the compromises. 2) our source code is littered with #ifdef, which makes maintenance difficult That's more reason to drop Arduino in IoTivity-full. > > If we're going to do Arduino, I again request that OCF provide a > > constrained profile first. > > That will be a question of demand driving priorities. It's my > impression that most of the OCF tech groups have their heads elsewhere > at the moment. So be it. If we take our cue from OCF priorities, constrained devices are not important and there's no point in spending too much effort. But I don't think you're right. I think there is a need for constrained and for the profile I mentioned. I will bring this up next week in the F2F. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
