Renaming rwp to readium, with its own repo

[HadrienGardeur]

Over the last few months, I've seen more and more interest in rwp and more specifically its ability to extract and infer metadata.

But through these meetings and calls, I've also noticed a great difficulty in naming this utility consistently. I've seen people call it:

• Go Toolkit
• Accessibility Enhancer
• Accessibility Extractor and Inferrer
• etc.

I think that this is essentially a communication issue, but one that will be hard to solve if we keep this great utility hidden in the current go-toolkit repository.

Since this is a multi-commands utility that could go beyond Readium Web Publications, I think that we should:

• rename the binary to readium
• move it to its own repository in the readium organization: readium/cli
• push it forward on the organization's README under our main projects
• and create a dedicated README focused on all the available commands along with parameters and examples on how to use them

I think this approach is also consistent with the current trajectory of this utility that could cover packaging, conversion and optimization commands in the near future.

Any thoughts @chocolatkey @mickael-menu @atomotic and others?

[mickael-menu]

Usually I'm in favor of keeping things in a single repo to ease maintenance, but I think in this case it makes sense:

• rwp is not intended only to integrators of Readium Web.
• rwp goes beyond the Go toolkit, and could actually use pieces from other toolkits or technologies.
• Having a single repo could help promote this tool which is useful beyond people doing reading apps.

I don't have a strong opinion about the name. rwp is fine and aligns well with our current sub-commands. But readium might be more future-proof. In any case, it should be clear that this tool is not simply called "Readium," as that could lead to more confusion. The Readium CLI sounds good.

[chocolatkey]

Regarding the naming, I don't think readium is a great choice, and if it's between that and rwp, I'd prefer rwp. I think readium is the name associated with all of the software under this GH org, as well as the efforts to standardize things like WebPub. Calling the tool readium seems inaccurate. It's not like I have a better name in mind though, but rwp works, and it's short, therefore easy to type. Maybe I'm just used to rwp though.

move it to its own repository in the readium organization: readium/cli

I'm OK with moving it to its own repo. There are dependencies that are only needed by rwp, and the codebase for it is only going to grow larger as we add more features. If we do that, the releases also move there right? And would the docker container (ghcr.io/readium/rwp) also be renamed?

push it forward on the organization's README under our main projects
and create a dedicated README focused on all the available commands along with parameters and examples on how to use them

That would be nice, and maybe advertise some use cases like self-hosting your book library

[HadrienGardeur]

I just feel that rwp will feel random for most people, especially if we call this project the Readium CLI.

Core maintainers of the project know that this stands for Readium Web Publications (mostly because we often use RWPM as an acronym), but since we won't necessarily limit what we can do to Web Publications, I'm not sure that's quite accurate either.

I agree that readium on its own would look strange, but it's not how this CLI is built.

In practice, we'll have readium manifest and readium serve. In the future we might have readium package, readium convert and readium optimize.

The optimizer will most likely target EPUB to EPUB optimizations, which is why I feel that using rwp is a little bit at odds with what we'll do in the future.

[HadrienGardeur]

If we do that, the releases also move there right?

That's correct, we would move the release over to the new repo.

And would the docker container (ghcr.io/readium/rwp) also be renamed?

Not necessarily. It depends what we end up calling it. Do we know the docker container is used? Playground, I imagine but anything else?

[llemeurfr]

I agree that rwp, as acronym of Readium Web Publications, does not represent what the CLI tool does.
It is true the readium, standalone, is too broad as a concept. With a primary parameter like serve, or transform it makes more sense IMHO.

[atomotic]

I don't dislike the name readium. It functions similarly to docker, where the name serves as the binary, the daemon, the entire container ecosystem, and the company name.

Regarding repository structure, I would also prefer a monorepo approach. However, I'm not clear about which features (and dependencies) should be exclusively included in the CLI that wouldn't be part of the toolkit packages.

[HadrienGardeur]

Regarding repository structure, I would also prefer a monorepo approach. However, I'm not clear about which features (and dependencies) should be exclusively included in the CLI that wouldn't be part of the toolkit packages.

I think some of the features of the package or optimize commands could be a good target for that.

In the past, you've explored the ability to handle transcoding for audio for example @atomotic, which I'm not sure would be a good fit for go-toolkit but could definitely be included in a CLI-oriented repo.

[HadrienGardeur]

For now we don't have full consensus but a majority of users seem to be in favor of:

• renaming rwp to readium (3 out of 4, I'm not counting myself)
• and using a separate repo for this CLI moving forward (2 out of 3)

We'll keep this discussion opened until the next Readium monthly call (April 2nd) to gather more votes.

[HadrienGardeur]

We didn't receive additional votes, so I've proceeded accordingly and created a new repo for the CLI.

Moving this discussion as well.