A few months ago, I looked into how I could streamline the implementation of the rss reader. The Sept. 2017 release was a step in that direction. Now, with the Nov. 2017 release, the refinement has continued with a version of the rss engine I finally find satisfactory. I decided to pull back from going too deep into the mechanics of handling file I/O. The POCO C++ libraries from Applied Informatics Software Engineering GmbH was a huge assist in this regard.
Some of the books I’ve been reading recently has informed some of my stylistic changes. Marius Bancila did a great job in his book, Modern C++ Programming Cookbook. His book showcases many stylistic changes coming in C++17. However, after reading his book, I decided to take a look at Haskell. Graham Hutton provides a solid description of the Haskell language. I have not finished Graham’s book, but what I have worked through gives me a sense that the right approach to abstraction definitely makes things more straightforward. Before that all that, I was reading David Vandevoorde’s C++ Templates: The Complete Guide. That book will either encourage you to seek better abstraction or go the other way.
The code that follows was done in the spirit of just enough abstraction to get things done. Hopefully, the code is defined in such a way to be able to jump back in after a few months. That is, hopefully it flows well upon reading as it did while writing it. The code is published to the Git repository at gautier_system.
The eventual goal is to have a solid RSS user interface. I’ve built a few, but they need to be powered by a solid foundation. A command-line interface is a great way to get there without the distraction of the visual definition process. The advantage of the cli is you can obtain fundamental functionality that you can use. As well, a cli works as a supporting mechanism to work out a foundational API. The following is the code for the cli portion. The following is intended to be compiled as an executable bound to an API representing an RSS object model.
RSS API – Collector
The collector does the actual work of grabbing the rss feeds and transparently saving them to an offline file for repeated viewing. The collector does this by going to a web address, pulling the rss information at that address. The rss information is then saved to a file. The collector then uses a parser to collect feeds into a data list that it then gives to the process that requested the information.
The stylistic goal in defining this module is to make the process more obvious. I make use of using aliases to reduce namespace clutter. I also attempt to use a few “different” data structures as possible. I eliminated the use of the std::map container since, at this level, I realized I don’t need overall list of feeds pre-sorted or denoted by feed source. The result is the structure and elements are more apparent.
RSS Feed Parser
The core of the API is the parser. It is hidden behind the collector because the how is not important from the standpoint of the application. In that sense, the parser is an implementation detail. However, effort was expended to simplify the parsing process. I realized that I didn’t need an approach that pushed for greater performance, speed, or brevity. While reviewing some computer science literature, I was reminded of the virtues of linked lists and decided that I will still achieve the goal of flattening the rss feeds but I need not process the rss input in that manner. Instead, I pursued an approach with more potential to be optimized stylistically as to make the process more obvious. At the same time, the translation occurs in a way that is potentially more robust.
The download of RSS need not be commingled with parsing or file processing. I took the network I/O part of the process and put it behind a thin abstraction. I am yet using other abstractions from the POCO C++ libraries and further wrapping those is for the benefit of the application. That way, the application only has to call a single function rather than represent the multiple steps to obtain the data at the application level.
RSS File Persist and Read
The RSS engine works best when the rss information that is pulled from a web address is then saved to a file. That way, a reliable source of information (a file folder) can be used regardless of the state of the network. A combination of exception handling and http output checking means that new data can be used, but if the new data is not available, old data is transparently used instead. The file abstraction provides the right function names and implementation for the overall rss engine to use towards that objective.
When the program executes, you get new feed information or old feed information depending on network conditions. The RSS API works and a better foundation for progress on this effort is established. The code I’ve written can run on Microsoft Windows, but I decided not to incorporate consideration of Microsoft Windows as part of my goals in the future. I’ll still use cross-platform approaches that should work on Windows in principle, but during creation and testing, these programs will definitely see more verification on Linux/BSD as a consequence of where they are created. The following screenshot is the program running on Fedora Workstation 26.