On sexta-feira, 29 de julho de 2016 06:25:16 PDT ?? wrote: > Repeating the Uze's point, why we need to focus on feature which is out of > scope for OCF spec & IoTivity?
Ok, so we shouldn't have this feature at all. There's no HTTP proxy feature in the OCF spec. Is that what you meant? If we follow that argument, then IoTivity should not implement Bluetooth LE nor the routing manager either, since those aren't spec'ed and go out of scope. We shouldn't implement plugin loading and interoperability with other protocols like the Philips Hue lightbulbs, as those aren't part of the OCF spec. There's some truth to that: we should have a solid implementation in the library that is exclusively the OCF core and nothing else. Layered on top of that, we could have extra and *optional* functionality, like bridges, plugin loading, proxying, etc. But our layer separation isn't very clear and we have things that have nothing to do with the OCF spec in the core library. Note that your statement supports my argument that the proxy should not be in the resources/ dir of the repository but instead in services/. > For your points , let me summarize in 2 aspects. > > > some websites require HTTPS > > > > websites that do have HTTPS should be accessed as HTTPS, even if they > > provide HTTP support > It?s not in scope of OCF and IoTivity. As said , incremental will be > justified instead of blocking the feature. The whole proxy is not in scope of OCF, therefore I don't accept your argument. Security and guiding users towards best Internet practices is in scope of IoTivity, which is why I think HTTPS needs to be in the first release. Security is not optional. > * a well-known HTTP library will implement HTTP better than the code > currently proposed > > * there will be an architectural change if we do HTTP first then HTTPS > > * using a third-party library will make some CA changes unneeded > > If we move the Proxy to Service layer , and use LibCurl or any other > library instead of CA directly, these all points will be addressed . we > agreed with Uze points to make additional APIs and move it to service > layer. Great. If we use libcurl, then we get HTTPS support "for free". > For your information , CA design changes are necessary for optimization . > Its not only for proxy. we will push them in other change set. Great again. Justify them individually and in separate commits from the proxy implementation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
