Christian, I took the time to work through all of the tickets that were in the filter. I was able to close a few of the issues as fixed, will not fix, or cannot reproduce.
If the 119 issues that still show up in the filter I saw 19 that maybe should be looked at again. There were a lot of tickets I simply don?t have the expertise to judge if they should be closed or open. Even some of the list ones I am not really sure. Quite a few of the tickets are analysis of the state of the code as a whole with some suggestions for improving. Because of the analysis it?s hard to recommend closing them. Many of the listed tickets are not defined in a way that they are easy to close and should probably be reworked to set a clear objective. https://jira.iotivity.org/browse/IOT-841 memory catastrophe in IoTivity A very complete analysis of IoTivity memory management. Places we need to improve to make IoTivity more reliable for running long periods of time https://jira.iotivity.org/browse/IOT-723 Remove all use of snprintf and sscan from the embeddable parts of the stack The primary justification for this change is for embedded stacks. Since iotitivity constrained is intended for embedded stacks this bug may not be as important as it was when it was introduced. I am not sure if the recommendation to remove all use is justified but in a lot of the code the suggestion could be used. https://jira.iotivity.org/browse/IOT-708 Subscribing to Presence is ill defined to the point of not working Bug points out places where subscribing to presence presence does not work. I am unsure if recent updates have addressed the issues. https://jira.iotivity.org/browse/IOT-653 Multi Hop using Routing Manager This is more a feature request. With a link to wiki page describing the feature. With a really long well written analysis in the comments of the ticket. https://jira.iotivity.org/browse/IOT-645 [Limits Build Server] SCons is generating output from dependencies in the 'extlibs' directory in the wrong directory; should be in the 'out' directory, but it generates them inside their respective library's home dir. This basically address the problem that building the extlibs causes problems with build process when building under different build options. The suggestion it to build extlibs in the out folder. This also has the benefit of isolating build output to one location instead of spread throughout the project. https://jira.iotivity.org/browse/IOT-619 RA xmpp scons need to execute the build directly with SConscript It is unclear if this is fixed or not (https://gerrit.iotivity.org/gerrit/#/c/1639 ) If this is not fixed this could cause intermittent build failures that are hard to track down. https://jira.iotivity.org/browse/IOT-601 C and C++ SDKs need to compile with GCC options {{-fvisibility=hidden -fvisibility-inlines-hidden}} Try a prevent polluting the global symbol space for the linker. https://jira.iotivity.org/browse/IOT-582 Iotivity's Android build process does not follow proper Gradle implementation standards. We have seen issues that the *.aar files may have missing libraries till a second build is completed it may be related to this issue. This also has a proposed solution and a commit that will need to be updated. I think this should be revisited. https://jira.iotivity.org/browse/IOT-540 Subsystem for Legacy ZigBee Devices Feature request to expose ZigBee devices as IoTivity resources. This may no longer be needed or needs to be reworked for bridging. https://wiki.iotivity.org/legacy_zigbee_device_support https://jira.iotivity.org/browse/IOT-519 Refactor #ifdef's as feature-based, not OS based No discussion in the comments. In general I think the suggestion is a good idea question remains if it is something that should be done in IoTivity https://jira.iotivity.org/browse/IOT-513 Fully implement 32-bit build processes in 64-bit SCons environment on Ubuntu. There was not justification for the ticket but often the only way for most developers to test and verify code for 32-bit is to build on their 64-bit system. This has a changeset that was done but abandoned. Relates to IOT-511. https://jira.iotivity.org/browse/IOT-497 Proposal for reduced file descriptor consumption https://jira.iotivity.org/browse/IOT-496 Change network interface monitoring Change how network interfaces are managed to reduce idle load and reduce code complexity. https://jira.iotivity.org/browse/IOT-494 Opportunities for simplifying CSDK Pointes out several problem areas that code complexity could be improved. (i.e. layers of calls, duplication of function, proliferation of structures, excess marshaling, misleading and confusing nomenclature, excessive use of threads). I think this is an important bug but it?s so big it should probably be broken up in to smaller tasks that can each be tracked instead of this monster list of problems. (this was also pointed out as an important ticket by Thiago Moura in a recent email regarding Arduino) https://jira.iotivity.org/browse/IOT-441 Make IoTivity restart system calls interrupted by Unix signals Make IoTivity handle EINTR system call properly. Looks like a lot of work was done on this issue. It?s unclear if more work needs to be done. https://jira.iotivity.org/browse/IOT-440 Make IoTivity CLOEXEC-safe Make IoTivity thread-safely when using open, dup, dup2, pipe, socket, and accept. Another one that looks like it was partially completed. It looks like it should have been handed off to another team. Unsure it this needs to be looked into deeper. https://jira.iotivity.org/browse/IOT-415 Cannot handle fast notification in ClientSever Mode Based on the comments on this ticket it is unclear if this is an invalid bug or if it should be looked into deeper. No really clear close case for this issue that I can see. https://jira.iotivity.org/browse/IOT-347 Building documentation not documented Is the wiki documentation enough to satisfy this ticket? If so it can be closed https://wiki.iotivity.org/generate_api_doc if not it still needs improvement. https://jira.iotivity.org/browse/IOT-122 Avoid using reinterpret_cast
