FeedPipe (Part 2)

I have not had any time to work on FeedPipe over the past three days, but I have continued to think about the design. This blog entry is a continuation of the previous FeedPipe blog entry.

Goals

The previous blog entry stated some goals for the project. The listed goals all affect the design and implementation of the FeedPipe software, but it is probably worthwhile to also state my goals for the indexes that FeedPipe helps create. FeedPipe users can provide their own HTML templates, CSS files, and JavaScript files, so they can decide on the priorities that are appropriate for each index, but the following goals are what I have in mind for the indexes that I create:

• The built web content should be as lightweight as possible, so that pages load quickly even for viewers with slow internet.
  • As I write this, the current Haskell books index page requires 5 requests with a total size of 45.6 KB. Testing using Pingdom, it loads in 553 ms in Tokyo (close to the server) and 1.19 s in London (far from the server). I hope that performance will be better when hosted on GitHub.
  • If viewers would like to include images of book covers, care should be taken to keep the image sizes small.
• The built web content must not require JavaScript. JavaScript can be used to enhance the functionality, but the index must be functional without it.

On a related note, I considered displaying the index in a table, using JavaScript to allow viewers to adjust how the index is sorted (when JavaScript is available). My primary reason for not doing this is that I would like to make the index easily viewable on narrow screens (mobile phones). I think that the current sort order is appropriate for the goal of discovering books. Perhaps the primary motivation for sorting by title is to confirm if a book is listed or not, but that can also be done by searching.

Current Design Notes

There is one significant change to the current design notes listed in the previous blog entry. I wrote:

Static files, CSS files, and JavaScript files can optionally be copied to specific output directories. Building of these files must be done before FeedPipe is run, which keeps FeedPipe simple.

I included this functionality with single index sites in mind, but the design is awkward when a site has more than one index that shares such resources. I think it would be better to make FeedPipe only generate HTML and RSS files. Static files (such as images), CSS files, and JavaScript files can be built/copied to the appropriate locations externally.

I will experiment with the design as I implement it, with a goal of keeping the single index use case simple.

Implementation Notes

Markdown

I was initially planning on using Pandoc to convert from Markdown to HTML, just because I love Pandoc. Since the software does not convert to/from any other formats, however, I realized that I should use a different library. I plan on proceeding with the cmark library.

There are some significant benefits to doing so: the executable file size will be much smaller and I will not have to license FeedPipe as GPL. Unfortunately, this means that Slick is no longer a viable option.

Templates

This website makes use of the ginger library to support Jinja-style templates. For quite some time, I noticed that the library fails to build when using GHC 9 but did not press the issue because GHC 9 was so new. Stackage nightly snapshots now use GHC 9, so I went ahead and investigated the issue today. It is a simplified subsumption issue! I created an issue on GitHub and submitted a pull request that fixes it. With this change, ginger now builds with GHC 9.0.1 without issue, with all tests passing.

Slick uses the mustache library to support Mustache-style templates. I may implement SitePipe to support Mustache as well as Jinja-style templates.