Why is Oculus writing a (non-VR) general purpose library?
Let me preface this by saying that I love my Rift, and I think that Oculus VR has a big future ahead of it. But its becomeing clear to me that OVR is spending valuable developer time writing general purpose classes. These classes duplicate existing free functionality.
Some examples:
Basically everything in the LibOVR/Src/Kernel subdirectory is an example of this. I'm really concerned about it, because every hour spent on extending this is an hour not working on VR specific stuff, or features the community wants. Writing a string class or a linked list class is something you do in a job interview, not in an SDK, or any kind of production code. These are solved problems. Right now almost half of your total lines of code in the SDK are in the Kernel subdirectory, implying almost half your development time has been spent doing stuff no one outside of OVR cares about or is ever going to use.
I've honestly tried to hold my tongue about this, but the lastest SDK version shows that OVR is not only not slowing or reversing this trend, but appears to be doubling down with the new inclusion of a JSON parser, again written from scratch and again, increasing the internal dependence on other duplicated functionality, like the String class. How much earlier would the Linux port have been released if writing a JSON parser you'd simply written #include <boost/property_tree/json_parser.hpp> or instead of writing a string class you'd written #include <string>.
I really can't understand why OVR would be doing this unless it's developers are either unaware of Boost and the Standard Template Library, or have a serious case of not-invented-here syndrome. If it's the former, I suggest you do a little bit of reading up, but if, as I suspect, it's the latter, I suggest you get over it and start focusing on your core deliverables, not these diversions. I know it's actively impeding my integration of your software, and I suspect I'm not alone.
Some examples:
- OVR_Atomic.h - A set of classes for atomic operations against types
- OVR_String.h - A basic String class
- OVR_List.h - A basic linked list container class
- OVR_Array.h - A basic linked vector container class
Basically everything in the LibOVR/Src/Kernel subdirectory is an example of this. I'm really concerned about it, because every hour spent on extending this is an hour not working on VR specific stuff, or features the community wants. Writing a string class or a linked list class is something you do in a job interview, not in an SDK, or any kind of production code. These are solved problems. Right now almost half of your total lines of code in the SDK are in the Kernel subdirectory, implying almost half your development time has been spent doing stuff no one outside of OVR cares about or is ever going to use.
I've honestly tried to hold my tongue about this, but the lastest SDK version shows that OVR is not only not slowing or reversing this trend, but appears to be doubling down with the new inclusion of a JSON parser, again written from scratch and again, increasing the internal dependence on other duplicated functionality, like the String class. How much earlier would the Linux port have been released if writing a JSON parser you'd simply written #include <boost/property_tree/json_parser.hpp> or instead of writing a string class you'd written #include <string>.
I really can't understand why OVR would be doing this unless it's developers are either unaware of Boost and the Standard Template Library, or have a serious case of not-invented-here syndrome. If it's the former, I suggest you do a little bit of reading up, but if, as I suspect, it's the latter, I suggest you get over it and start focusing on your core deliverables, not these diversions. I know it's actively impeding my integration of your software, and I suspect I'm not alone.