Currently, there is no limit on the number of posts listed on index pages, nor is there a limit on how many posts the getPosts function attempts to read from the file system.

I'm just dropping some ideas here as several approaches could be used for a solution:

• Pagination
• Capped listing (count-based). Posts beyond that cap would be listed in an "archives" section, which would then need some sort of pagination.
• Pagination combined with a logic of using subfolder to do some "organization". Through periodic "chores", the blog owner(s) could move any .md file into a subfolder (e.g archives/), which would act as a high-level "filter"; removing posts located in any subfolder(s) from the main "index" listing. However, the posts should still be served on their :slug (derived from their filename) on the "root route" of the blog (permalink – we don't want redirect, canonical link, here the unique "state" is the file system). However, this might also collide with the concept of subject which should be supported through frontmatter (see #3). The subfolder(s) could be anything, "archives", an arbitrary "category" (which might overlap with subject?), or something like a full year number or any other logic allowing a more fine-grained archiving logic. The subfolders could have a certain level of nesting depths too.
• ...?

One might want to use a hands-on approach for the "index" route of his blog. Building his page with various components which would highlight the posts of his choice, etc. In any case some kind of "pagination" might needs to exist at some levels (e.g for filters results of posts by tags, subject, etc)

Note: this is a different problem than #7 and this is likely to require a different solution, while the same underlying data method getPosts might be involved.

This problem and any potential solution will need more shaping... I feel there are more rabbit-holes to this than I'd like.

https://mystmd.org/guide/frontmatter

• title
  • max 500 chars limit
• short_title – 3197db6
• name – not sure if this is relevant
• description
  • max 500 chars limit
• tags
• thumbnail
• subtitle
• date
• authors
• affiliations
• doi
• arxiv
• open_access– open_access: not sure if this has any merit in this context
• license
• funding
• github
• binder – what is this?
• subject (max 40 chars)
• venue
• biblio – not clear what's the purpose, how this is used
• math – add some challenges in processor
• abbreviations
• parts – what is this?
• options – not sure if this will be ever needed in this context

See the following tests

Simply cache the results of processing the markdown files. The cache should be invalidated any time the markdown file changes.

This might be necessary to #5.

Deno dependencies aren't located in any local "vendors" folder (e.g node_modules), thus using relative paths in the tailwind.config.ts file won't work.

The instruction in the README or in the example folder are misleading.

I'm not quite sure how to solve this right now...

This might be a 🐇🕳️

The current library used to create the feeds do not support pagination: jpmonette/feed#84

This is also a gray area in RSS 2.0, in other ATOM & JSON this is well supported.

RSS 2.0

RSS 2.0 itself does not inherently support pagination. The RSS 2.0 specification, as originally released, focuses on providing a feed format for delivering updates to users, including items such as news articles, blog posts, and other content. The specification includes elements for describing the feed and its items but does not include built-in features for pagination, which would allow clients to fetch a subset of items based on a specific page number or limit.

However, pagination can still be implemented with RSS 2.0 feeds through various approaches, depending on the requirements of the publisher and the capabilities of the consuming application. Here are a few common methods:

1. Custom Elements: Feed publishers can add custom elements to their RSS feeds to indicate pagination controls or information. These might include elements specifying the current page, total number of items, total pages, and links to next or previous pages. Consuming applications that understand these custom elements can then use them to navigate the feed in a paginated manner.

2. Feed Segmentation: Publishers can segment their feeds into multiple, smaller feeds based on criteria such as date ranges, categories, or arbitrary pagination. Each segmented feed would represent a "page" of content. This approach requires the consumer to know how to access these segmented feeds, typically through different URLs.

3. Query Parameters: Some feed providers allow clients to request paginated feeds by appending query parameters to the feed URL (e.g., ?page=2&limit=10). This approach is controlled by the server-side implementation and requires the feed consumer to modify the feed URL according to the pagination scheme supported by the provider.

4. Link Elements: Although not a standard part of RSS 2.0, some feeds include <link> elements (not to be confused with the standard <link> element within an item) or other mechanisms in the feed metadata to provide URLs for pagination. These links can point to the next, previous, first, and last pages of content.

It's important to note that since these methods are not standardized within the RSS 2.0 specification, their support and implementation can vary widely. Consumers of RSS feeds need to rely on documentation provided by the feed publishers or inspect the feeds to determine if and how pagination is implemented.

Atom 1.0

Atom 1.0, unlike RSS 2.0, includes built-in support for pagination, which is a significant advantage for managing large feeds or for applications needing to process feed data in chunks. Pagination in Atom feeds is commonly handled through the use of link elements with rel attributes indicating their relationship to the current feed document. Here's how it works:

Pagination Elements in Atom 1.0

• <link rel="next">: This link points to the next "page" of entries in the feed. It indicates that there is more content available beyond what is currently being viewed or processed.
• <link rel="previous"> or <link rel="prev">: Similar to the "next" link but in the opposite direction. It points to the previous page of entries, allowing navigation to earlier content in the feed.
• <link rel="first">: Points to the first page of entries in the feed. This can be useful for users or applications that want to navigate to the beginning of the feed content.
• <link rel="last">: Points to the last page of entries. This allows users or applications to jump directly to the most recent content, regardless of their current position in the feed.

Example

In an Atom feed, pagination links might appear as follows:

<link rel="first" href="http://example.com/feed?page=1" />
<link rel="prev" href="http://example.com/feed?page=2" />
<link rel="next" href="http://example.com/feed?page=4" />
<link rel="last" href="http://example.com/feed?page=10" />

Implementation Notes

• Dynamic Content: Since Atom feeds often represent dynamic content (e.g., blog posts, news articles), the pagination links can change as new content is added. Clients consuming the feed should be prepared to handle these changes.
• Server-Side Support: Effective pagination requires support from the server generating the Atom feed. The server needs to calculate and insert the appropriate pagination links based on the total content available and the current position within that content.
• Client-Side Processing: Clients consuming Atom feeds with pagination support should be able to recognize these link elements and use them to navigate through the feed content efficiently, fetching additional pages of entries as needed.

Pagination in Atom 1.0 feeds provides a standardized way to navigate through large sets of feed entries, making it easier for both publishers and consumers to manage and consume feed content effectively.

JSON Feed 1.0

JSON Feed 1.0 supports pagination in a straightforward and flexible manner, similar to Atom 1.0, by utilizing link objects within the feed. These link objects can specify URLs for the next page of content, previous page, and other navigational links, depending on the publisher's implementation. Here's how it works:

Pagination in JSON Feed 1.0

• next_url: This is a key in the JSON Feed object that points to the URL of the next page of items. When present, it indicates that there are more items to fetch beyond what is included in the current feed document.
• _prev_url: Though not officially part of the JSON Feed specification, some implementations might include a similar key for the previous page URL, following the naming convention (_prev_url) or a similar one, to maintain consistency with next_url. However, because this is not standardized, its support and naming could vary.

Example

A JSON Feed with pagination might look something like this:

{
  "version": "https://jsonfeed.org/version/1",
  "title": "My Example Feed",
  "home_page_url": "http://example.com/",
  "feed_url": "http://example.com/feed.json",
  "items": [
    {
      "id": "2",
      "content_text": "This is a second item.",
      "url": "http://example.com/second-item"
    },
    {
      "id": "1",
      "content_text": "This is a first item.",
      "url": "http://example.com/first-item"
    }
  ],
  "next_url": "http://example.com/feed.json?page=2"
}

Implementation Notes

• Flexibility: JSON Feed allows for a flexible implementation of pagination, with the primary method being through the next_url. Publishers can also include custom keys for additional navigational links if they choose, but such implementations should be documented for consumers of the feed.
• Dynamic Content Management: As with Atom, managing dynamic content via pagination in JSON Feed requires the publisher to dynamically generate the next_url (and potentially other navigational links) as content is added or as the feed is requested.
• Client-Side Handling: Clients consuming JSON Feeds should be prepared to handle pagination by detecting the presence of next_url and making additional requests as needed to fetch the entire content of the feed.

Pagination support in JSON Feed 1.0 makes it easier for both publishers and consumers to manage and navigate large sets of data in a feed, providing a simple yet effective mechanism for content discovery and consumption.

Push content to feed items