Naming our repos

[HadrienGardeur]

In the last few years, we've had to be careful about the way that we call our current set of projects: what was initially called "Readium-2" became simply "Readium" with three main projects:

• Readium Mobile
• Readium Web
• Readium Desktop

For this reason, we now have an inconsistency in how we name our repos:

• early on, all repos had an r2 prefix followed by the module name and the language used (the initial repo being r2-streamer-go)
• for our main projects, we simply use their names: web, mobile and desktop for example
• a number of other projects also use readium as a prefix: readium-css, readium-lcp-server and historical projects like readium-js

The Go repo is slightly different from any of these repos:

• it doesn't contain a single module/component like most r2 prefixed repo
• it's not really a "main project" but could potentially interact with a number of them (for example serve Web Publications to Readium Mobile, Desktop or Web based apps)

For the sake of consistency, I think that we need a rule of thumb to decide how to name things moving forward. I would recommend:

• dropping the r2 prefix moving forward and simply using component-language, so for example r2-shared-swift would eventually become shared-swift
• drop the readium prefix as well from non-historical projects, so for example readium-lcp-server would become lcp-server (which is consistent with what we do in other repos anyway, for example webpub-manifest)
• for language specific repos that do not contain a single component, we could use language-toolkit so r2-streamer-go would become golang-toolkit or go-toolkit

[llemeurfr]

I'm globally ok with this move, provided that it is done at the time major versions of the different toolkits are released. Or for new toolkits (a Flutter/Dart one comes to mind).

The slightly annoying side is that a streamer in golang will be named streamer-go where a mono-repo toolkit will be named go-toolkit (go last of first).

Logically, a mono-repo Readium Web should be therefore renamed ts-toolkit and Readium Desktop renamed electron-toolkit.

[danielweck]

ts-toolkit ... I would have thought web-toolkit?

[HadrienGardeur]

Well, ideally we should use the project name if possible.

A rule of thumb would be: project > project-language > language-toolkit > module-language

So:

• web > ts-toolkit
• desktop > electron-toolkit
• if we ever move to mono repos for Readium Mobile, we would have mobile-kotlin and mobile-swift

In the case of the go-toolkit, it isn't tied to a particular project as you could leverage it for many different use cases:

• Publication Server for a Readium Web based app
• Publication Server for a Readium Mobile based app
• Publication Server for a Readium Desktop based app
• Generating samples
• Adding a watermark to an EPUB on the fly
• Converting a CBZ/CBR to a Divina
• etc.

[mickael-menu]

I'm not a fan of the mobile-kotlin and mobile-swift names, because:

• Technically both Swift and Kotlin could also be used to create CLI tools like Go, using the shared models.
• Even though the codebase is not ready for this, both Swift (with SwiftUI) and Kotlin (with KMP) could be used to build desktop apps as well.
• We actually refer to "Readium Kotlin Toolkit" and "Readium Swift Toolkit".
• The naming could be confusing when we have on the other side ts-toolkit and go-toolkit.

So I'm in favor of using kotlin-toolkit and swift-toolkit. Keeping the project-language template for very specific repos like the LCP server one.

[killerpuppytails]

I am also in favor of using kotlin-toolkit and swift-toolkit as it is easier to maintain over time.