Skip to main content

Abort FeedPipe?

A few weeks ago, in FeedPipe Design, I wrote:

I have been working on an updated design, and I started to wonder if I should just abort FeedPipe and focus on the website software instead, since the website software can be used to achieve the same goals as FeedPipe…

After much deliberation, I have decided to continue with FeedPipe, using a design based on my website software. FeedPipe will provide an easy way to maintain static indexes and RSS feeds. My website software, which will be released as open source when it is ready, will include the same functionality in addition to many other features and options.

Though I was distracted by Aeson Object Design for a while, I have since been been working on FeedPipe again. Making the design more like my website software has led to great improvements, but I am once again wondering if it is worth developing FeedPipe separately. As I develop FeedPipe, I have been making changes to provide source compatibility with my website software, and I think it may be easier to maintain one project than two.

To help assess the situation, I made a list of features that are supported by the website software but not FeedPipe. There are probably things that I am forgetting, but I think I remembered the big ones.

Clean URLs

The website software supports “clean” URLs. I do not like how many static sites use URLs that end with a slash (example: https://example.com/foo/) where the same page can be accessed using index.html (example: https://example.com/foo/index.html). This is done because the static site can be served directly by pretty much any web server (such as Nginx or Apache). I prefer having a single URL for content. The website software has a server component that can provide non-static as well as static functionality, so it is easy to also provide “clean” URLs.

I have already added support for “clean” URLs to FeedPipe, and I realized that I could add directory URLS (foo/) and file URLS (foo.html) to the website software… To use the website software to produce a FeedPipe-style static site, one would simply configure it to use directory (or file) URLs.

Articles

The website software includes an article system for organizing articles like in the articles section of this website.

  • The articles index is created automatically, sorted by article title.
  • Article series are supported, where multiple articles are grouped together. Series pages link to the series index. Series articles are displayed hierarchically in the articles index, either unordered or ordered according to the metadata for the series.
  • It is possible to only list the series index of an article series in the articles index. This prevents series with many articles (such as Haskell Books) from making the articles index too long.

When using the website software to produce a FeedPipe-style static site, the articles system can be ignored.

Blog

The website software includes a blog system for organizing a blog like in the blog section of this website.

  • The blog index is created automatically, sorted by blog entry publish date.
  • Blog URLs include the date as directories, and the server redirects to the index when you access a date URL. For example, accessing /blog/2021/08 redirects to the blog index with an anchor that indicates the selected month: /blog#t-2021-08. Currently, the blog index is just a long list, but a calendar UI could be implemented for easier navigation in the future.
  • Blog entry source files can be organized in a number of ways, to allow authors to organize source files in the way that is most convenient for their use. Source files can be grouped by year, month, or day depending on how many entries there are for that period of time. For example, the source for this blog entry, which does not include any special assets, could be any of the following:
    • blog/2021/09/23-abort-feedpipe.md
    • blog/2021/09-23-abort-feedpipe.md
    • blog/2021-09-23-abort-feedpipe.md

When using the website software to produce a FeedPipe-style static site, the blog system can be ignored.

Tags

The website software has support for hierarchical tags.

In Haskell Books, I do not use this tag functionality to categorize books because book tags are separate from the site tags. On a site that is just for Haskell content, however, this tag functionality could be very helpful, since RSS feeds are created per tag. For example, tags like algorithms:book and algorithms:paper would allow people to subscribe to feeds for any algorithms content, books about algorithms, or papers about algorithms.

Source Formats

The website software has support for many source formats. Use of Pandoc allows use of Pandoc Markdown with syntax highlighting. Use of LiterateX allows use of literate markup in the source code of many programming languages, etc.

When using the website software to produce a FeedPipe-style static site, such functionality is probably not needed. Power users can always compile their own “builder” program and include support for source formats as required, but I can provide two general builds:

Draft Mode

The website software has support for “draft mode.” An article or blog entry that is marked as a draft is not included in indexes or feeds, and a notice is displayed on the page. Drafts allow others to review or proofread content before it is published.

When using the website software to produce a FeedPipe-style static site, this feature can be ignored.

Metadata

The website software has support for a lot of different types of metadata, such as the following:

  • authors
  • proofreaders
  • translators
  • language
  • related articles
  • related blog entries
  • …

Most metadata does not need special support by the software, since users just include the metadata and make use of it in templates.

The website software supports a “people database” (YAML file) that is used to define identifiers for specifying authors, proofreaders, and translators. This is not really necessary, however, and I have been thinking about removing it. If removed, such metadata needs no special support.

The language metadata is an artifact of the first version of the website software that I wrote (over ten years ago?!?!), when I had a website that was fully localized. I have been thinking about removing it, as the templating system is sufficient for most needs. Templating should indeed be sufficient for a FeedPipe-style static site.

Author

Travis Cardwell

Published

Tags
Related Blog Entries