Thoughts about RadKade
So, essentially I thought that I would just write a small post to further elaborate on what RadKade is going to be and the direction it is going to take down the road. I have written this to some degree, but never fully explained in detail what it was I was thinking when designing the system. So, if you feel like a little read about our future and what is in store down the road, or if you are just curious about the creation of a frontend then stay all the same. If you have any questions about the development process or anything please feel free to let me know.
The RadKade Model
Well, this is more a personal belief and not factual; but we feel that every aspect of a frontend should be open to the public and provided at no cost. One thing is certain, the creation of a frontend is not technically difficult; as a matter of fact it is quite simple (especially if you are using external libraries to lift most of the code for you.) RadKade will use external libraries to render its graphics (more specifically OpenGL 3.0 and SDL (depending upon what your system supports), DirectX will not be supported in this release or subsequent releases) as well as external database libraries. In order for a library to be included in RadKade IT MUST be open source and readily available to the public (also maintained). We at no time will use external proprietary encoding/decoding drivers to handle our payload, nor will we rely on any commercial library or device driver (as that goes against our core beliefs).
There are a lot of really nice frontends out there (RetroFE comes to mind) that are already open source and available to the public at zero cost and for that we are grateful and we applaud those authors. On the other side of the token there are commercial frontends (which in and of itself is fine), but it's the frontends with hidden costs that irratate us (you can download the app for free but to get the media (which they do not own by legal definition) easily you have to buy ("donate") to their services.) Our model is one of the public meaning that anybody who wants the application will be entitled to all content therein at no charge, and we completely operate within the confines of legal terms and respect all DCMA request promptly. Furthermore, we believe that the public should be entitled to the natural source code of the frontend to inspect and verify the integrity of the project and all of its components (as some aspects of our frontend will periodically submit information (not limited to) error reports, twitter/facebook integration methods, forum logins and other various network utilites.
The Core Programming
Trust us when we say we have experimented with various programming languages (fun fact: the first RadKade was developed in WPF) and methods to make our dream become a reality. At the end of many months of benchmarking, testing and development we have decided to use Java 1.8 as the backbone of the application. Our application will be built using the LibGDX libraries and methods. You might be asking yourself "why Java", and the answer to that is quite simple: human readability. We wanted anybody to be able to pick up our source code and understand it (without being a professional developer.) In an application such as an arcade frontend Java fits the bill quite well as it is portable, well documented/structured and easily accessible. Before I go much further allow me to clear up any ignorance regarding Java that may exist.
At the end of the day (and I am sure an Java developer will agree with me here), it's not so much the framework that screws your program over, it's the programmer. If you program sloppy, don't clean up objects or other unused trash it will sit in memory and leak like a boat with a hole in its side. Please understand that I am not writing this article to defend why we are using Java, I am writing it to inform you of our choice to use Java. I have been a .NET developer (professionally) for going on ten years and every single time if given the choice between .NET and Java I would choose Java. Now, I am not saying .NET is bad or anything but I really just don't care for certain aspects of it (mainly being the fact I can't run the programs on my Linux machine (minus MONO built applications) but that is somewhat of a myth there too which we will touch on another day perhaps.)
Database Management
During your time with other frontends you have probably gotten used to the XML databases. While technically XML databases do serve a very good purpose and are totally feasible do not expect to see them make an appearance in RadKade whatsoever. RadKade is using SQL (adapters included) to handle its own private databases. Our backend system will allow users to browse through the entire database, edit information and access data on the fly with minimal lag. Essentially what this means is instead of holding one XML file in a memory object for each system we are going to have a master database that holds information for all systems therein. We have chosen this method because in our opinion it is easier for people to just setup and go if they don't have to worry about keeping external XML files up to date, or have to sift through thousands of lines (in most cases) of XML data to find something they are looking for; instead they can simply search by title, description, genre or manufacturer to find what they want.
Don't fret though our SQL database system is able to be packed and moved to various RadKade installations around globally. You will not need to worry about having the latest SQL drivers as they are prepackaged into RadKade directly (open source of course) so that from the moment you download, unzip and install RadKade you can start editing immediately.
Packaging
Love your RadKade setup and want it on another machine? No problem, we've got you covered as RadKade comes with a built in packer that will allow you to effortlessly move your RadKade installation (partial or whole) to another system via network (Internet/Lan) 256AES encryption, External media device.
Conclusion
So with everything here being said we are still very excited about the future of the RadKade project and expect big things to come from it. Our working philosophy is that if RadKade makes a small group of people happy then we have done our job right. We are also currently investigating other server options as GoDaddy seemed to bomb out (great for registering a domain) in terms of actual hosting. Probably be 2-14-2015 we will have made our final selection on server hosting (as it is in heavy talks at the moment) based on the server that can meat our global needs and the needs of the community. So, if you have any questions about RadKade in the meantime feel free to discuss them here with us on the space that DJVJ has so generously provided for us, and thanks for reading!
So, essentially I thought that I would just write a small post to further elaborate on what RadKade is going to be and the direction it is going to take down the road. I have written this to some degree, but never fully explained in detail what it was I was thinking when designing the system. So, if you feel like a little read about our future and what is in store down the road, or if you are just curious about the creation of a frontend then stay all the same. If you have any questions about the development process or anything please feel free to let me know.
The RadKade Model
Well, this is more a personal belief and not factual; but we feel that every aspect of a frontend should be open to the public and provided at no cost. One thing is certain, the creation of a frontend is not technically difficult; as a matter of fact it is quite simple (especially if you are using external libraries to lift most of the code for you.) RadKade will use external libraries to render its graphics (more specifically OpenGL 3.0 and SDL (depending upon what your system supports), DirectX will not be supported in this release or subsequent releases) as well as external database libraries. In order for a library to be included in RadKade IT MUST be open source and readily available to the public (also maintained). We at no time will use external proprietary encoding/decoding drivers to handle our payload, nor will we rely on any commercial library or device driver (as that goes against our core beliefs).
There are a lot of really nice frontends out there (RetroFE comes to mind) that are already open source and available to the public at zero cost and for that we are grateful and we applaud those authors. On the other side of the token there are commercial frontends (which in and of itself is fine), but it's the frontends with hidden costs that irratate us (you can download the app for free but to get the media (which they do not own by legal definition) easily you have to buy ("donate") to their services.) Our model is one of the public meaning that anybody who wants the application will be entitled to all content therein at no charge, and we completely operate within the confines of legal terms and respect all DCMA request promptly. Furthermore, we believe that the public should be entitled to the natural source code of the frontend to inspect and verify the integrity of the project and all of its components (as some aspects of our frontend will periodically submit information (not limited to) error reports, twitter/facebook integration methods, forum logins and other various network utilites.
The Core Programming
Trust us when we say we have experimented with various programming languages (fun fact: the first RadKade was developed in WPF) and methods to make our dream become a reality. At the end of many months of benchmarking, testing and development we have decided to use Java 1.8 as the backbone of the application. Our application will be built using the LibGDX libraries and methods. You might be asking yourself "why Java", and the answer to that is quite simple: human readability. We wanted anybody to be able to pick up our source code and understand it (without being a professional developer.) In an application such as an arcade frontend Java fits the bill quite well as it is portable, well documented/structured and easily accessible. Before I go much further allow me to clear up any ignorance regarding Java that may exist.
Java is slow
While this used to be 100% true it is absolutely false in this modern age of computing. Since Java 1.4 Java is actually almost on par with C++ and runs (typically) substantially faster than most non-c based languages. This is due to the fact that Javas JIT compiler being overhauled by Sun to make sure that code that operates frequently is highly optimized
Java is riddled with memory leaks
Once again this used to be accurate; but now Java has amongst some of the best garbage collection around.
While this used to be 100% true it is absolutely false in this modern age of computing. Since Java 1.4 Java is actually almost on par with C++ and runs (typically) substantially faster than most non-c based languages. This is due to the fact that Javas JIT compiler being overhauled by Sun to make sure that code that operates frequently is highly optimized
Java is riddled with memory leaks
Once again this used to be accurate; but now Java has amongst some of the best garbage collection around.
At the end of the day (and I am sure an Java developer will agree with me here), it's not so much the framework that screws your program over, it's the programmer. If you program sloppy, don't clean up objects or other unused trash it will sit in memory and leak like a boat with a hole in its side. Please understand that I am not writing this article to defend why we are using Java, I am writing it to inform you of our choice to use Java. I have been a .NET developer (professionally) for going on ten years and every single time if given the choice between .NET and Java I would choose Java. Now, I am not saying .NET is bad or anything but I really just don't care for certain aspects of it (mainly being the fact I can't run the programs on my Linux machine (minus MONO built applications) but that is somewhat of a myth there too which we will touch on another day perhaps.)
Database Management
During your time with other frontends you have probably gotten used to the XML databases. While technically XML databases do serve a very good purpose and are totally feasible do not expect to see them make an appearance in RadKade whatsoever. RadKade is using SQL (adapters included) to handle its own private databases. Our backend system will allow users to browse through the entire database, edit information and access data on the fly with minimal lag. Essentially what this means is instead of holding one XML file in a memory object for each system we are going to have a master database that holds information for all systems therein. We have chosen this method because in our opinion it is easier for people to just setup and go if they don't have to worry about keeping external XML files up to date, or have to sift through thousands of lines (in most cases) of XML data to find something they are looking for; instead they can simply search by title, description, genre or manufacturer to find what they want.
Don't fret though our SQL database system is able to be packed and moved to various RadKade installations around globally. You will not need to worry about having the latest SQL drivers as they are prepackaged into RadKade directly (open source of course) so that from the moment you download, unzip and install RadKade you can start editing immediately.
Packaging
Love your RadKade setup and want it on another machine? No problem, we've got you covered as RadKade comes with a built in packer that will allow you to effortlessly move your RadKade installation (partial or whole) to another system via network (Internet/Lan) 256AES encryption, External media device.
Conclusion
So with everything here being said we are still very excited about the future of the RadKade project and expect big things to come from it. Our working philosophy is that if RadKade makes a small group of people happy then we have done our job right. We are also currently investigating other server options as GoDaddy seemed to bomb out (great for registering a domain) in terms of actual hosting. Probably be 2-14-2015 we will have made our final selection on server hosting (as it is in heavy talks at the moment) based on the server that can meat our global needs and the needs of the community. So, if you have any questions about RadKade in the meantime feel free to discuss them here with us on the space that DJVJ has so generously provided for us, and thanks for reading!
