[Discussion] Let's define de project in more details

[llemeurfr]

From discussions I had yesterday with @JayPanoz and @aferditamuriqi, the goals and definition of the project itself are not so clear.

The overall goal is to develop an SDK (i.e. a consistent set of modules with a clear API) conforming with the Readium Architecture, plus a test app, enabling reading on different browsers different types of publications exposed via a Readium Publication Server (ex. "Streamer").

Is it enough? What do we need to add in order to create proper directions and roadmap for the project?

The thread is to allow project stakeholders to express their opinion on the subject and should end with a common detailed definition of the Readium Web project.

[JayPanoz]

Alright so I tried to find a document for the readium-web call we had back in November 2018 (?) but couldn’t find it unfortunately; I could re-read the doc I’ve been sharing about needs (and requirements) tho.

So apologies in advance if some parts are vague recollections of what was said during the call – I’ll do my best to avoid those.

So I guess the most important points of my doc were that:

1. use-cases are a very large spectrum – and we’ve found out in real life that it was even larger than I anticipated –, and in a lot of those use-cases, you don’t necessarily need some modules/features;
2. which is the reason why I strongly preferred a “pick and build” approach – not having to remove a lot was the top reason we did not use other options.

However, this needs some nuances.

Firstly, code-splitting/lazy-loading can already offer a lot of remediations – and say if you don’t enable a feature, its module won’t be loaded. It’s pretty much a MUST for web apps anyways, because of performance concerns, etc.

A personal note: at first sight, if we agree that is important and should be part of the test-app, the “webpack commit” may well be something critical at the very start, so that we can adopt a set of common rules for adding modules, etc. and don’t have to care about it once things are merged. Having made some experiments with it, I’d be more than happy to use it if others want to use it too.

Secondly, and that was mentioned during this call, you also have a lot of users who just want something simple to modify and use. Literally some people just want to change files to customise the reader, copy/paste some code in which they can modify options and voilà – which means that in some cases they don’t even want to “rebuild.”

This is probably where a tension arises between what the SDK is trying to achieve, and what the test-app should be. At the time, and I’d be more than happy to be corrected if the following is wrong, it seemed to me we couldn’t necessarily decide how to handle that “simple to modify and use” case.

I thought that maybe the test app could serve this purpose – because I saw a lot of external developers start with the Kotlin and Swift test apps – at first, but can’t recall all the details of the conversation. All I can remember is that it wouldn’t necessarily want to achieve that goal. Maybe it would be a good idea to focus on this one, since I’m pretty sure we will all agree about the definition of the SDK?

[jccr]

Given the usual definition of an SDK. I do not agree that it should be that way.

[JayPanoz]

Yeah well, I’m clearly admitting that discussion during this call lost me. Sorry if it did not transpire in my previous comment, it wasn’t the intention.

[jccr]

And I'll admit I didn't read your message in detail. My comment, in general, was about thinking of the product as an SDK. This isn't the way to go in my opinion. I am interested in the idea of picking and choose from a multi faceted, multi featured app with a single codebase.