Hi Pat/Thiago, As far as I know, the development process which has been discussed during ISG Meeting on May in Seoul, is that Design should be on the wiki page and shared. I expected that this is to gather the F/B from community Regardless of detail step after design share on wiki, Maintainer (with Architect) is responsible to approve the design.
BR, Uze Choi From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Lankswert, Patrick Sent: Friday, July 24, 2015 12:10 AM To: myeong.jeong at samsung.com; Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: Re: [dev] CAGetNetworkInformation() function does not work To all, I have to agree with Thiago. If this is not standards based work then this is an iotivity activity. If it is an iotivity activity, the discussion needs to happen on the mailing list and captured decisions including design need to be posted to the wiki. Thiago, What we lack though is a way for the community to say ?yes let?s do it? or indicate ?we approve?. Pat From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ??? Sent: Thursday, July 23, 2015 3:41 AM To: Macieira, Thiago; iotivity-dev at lists.iotivity.org Subject: Re: [dev] CAGetNetworkInformation() function does not work Thiago, Please check the following URLs before understanding what Routing Manger does : https://wiki.iotivity.org/routing_through_heterogeneous_transports Its not for IPV6 .ts for heterogeneous transports.( like IPV4, BT , BLE) And, followings are comments : "This feature has never been described and its needs are not understood. As far as I can tell, it's not part of the spec, in any version I've seen. We're asking that you share this information so we can come up with a proper, long-term solution." >> Please attend the dc tg cc's before saying never been described. we >> communicated many times in the cc. we are planning to propose it in Spec C as spec A and spec B timelines are freezed . "IoTivity has no bi-weekly calls or any call at any frequency. If you're meeting outside of IoTivity, please post any conclusions to the mailing list." >> Discovery & Connectivity task group has its bi-weekly calls. We are attending the dc tg calls from long. If you are not aware, please check with Pat. Already dc tg maintainer posts the MoM. Thanks. Best Regards, --- MyeongGi Jeong Senior Engineer, Software Architect Software R&D Center, Samsung Electronics Co., Ltd. +82-10-3328-1130 ------- Original Message ------- Sender : Thiago Macieira<thiago.macieira at intel.com> Date : 2015-07-23 00:48 (GMT+09:00) Title : Re: [dev] CAGetNetworkInformation() function does not work On Wednesday 22 July 2015 05:05:22 ??? wrote: > We are not sure why you are saying unwise and unnecessary. > It??s up to the API user to use any internal APIs. > Currently Routing manager requires the GertNetworkInformation to know the > available networks and route the packet. Can you describe why the code requires the information in order to do routing? The operating system already has the routing tables and knows the routes and IP addresses better than we do. Therefore, the operating system already does routing better than we can in IoTivity. So why do we need to do routing at all? This feature has never been described and its needs are not understood. As far as I can tell, it's not part of the spec, in any version I've seen. We're asking that you share this information so we can come up with a proper, long-term solution. > The main subject of the mail is > because of your changes, this API is not working. The API might be flawed. We need to establish whether it makes sense before we go back to inserting code to support it. > Only Application devlopers required to use C or C++ APIs. > Any feature contributors can use internal APIs and any feature can have unit > test cases and samples to make sure all units are functional. If you feel > an internal API is unnecessary, please raise the issue during the biweekly > CC or through the dev-mailing list before you changes. IoTivity has no bi-weekly calls or any call at any frequency. If you're meeting outside of IoTivity, please post any conclusions to the mailing list. You're right that IoTivity features can use the internal API. But the IoTivity feature itself needs to be unit-tested so we can catch the breakage when the changes are done. I'd like us to investigate why the failure was allowed to happen in the first place. -- 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 <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=0fa18573320d6211ce680a47a6c1c34e58ef0e8a7653647a032aa89e99be1a3e13d69ea60670f66e1fac5bf6c61543587bc8a6096cfbfc9f02e038c8d853bffbdb9fdddda33e82cbe4a391424e62fcf6cf878f9a26ce15a0> -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150724/9e81b497/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150724/9e81b497/attachment.gif>
