Define a roadmap for Readium-2 about architecture HOT 41 CLOSED

Re the "2" name, Angular 2 has not killed Angular 1, Python 3 has not killed Python 2. An evolution does not mean an immediate replacement. The tech guys you meet should know that.

from architecture.

I'm fine with the idea of an overall roadmap but versions are usually quite difficult and will be even more difficult for a project broken down into multiple modules and implementations of each module.

from architecture.

I think a good place to start is mvp target feature set (e.g. what the initial committed implementers will need in order to to ship), then document agreed tech spec/architecture. I don't personally think it is important or particularly useful to try to predefine dot release feature sets that are post MVP. Wish list is of course handy for vetting proposed tech spec though. I'm not sure that tentative roadmap beyond that is particularly useful either. I'm a fan of the agile approach using sprints. As you point out in your 3/ timeline is not knowable, so 2/ can not be answered other than to clarify that it is not answerable. That said, I would assume we all agree that R2 certainly won't be a complete and total replacement for R1 iOS SDK or R1 Android SDK in 2017 nor early 2018 so such guidance might assuage the concern if shared?

from architecture.

To Clarify, my comment above, when I was referring to iOS SDK and Android SDK I was referring to the full stack of REadium projects one would usually use when creating an app. The "SDK" is a particular project in github that is a subset of that full stack, and thus my use of that term could be misinterpreted. What is a better "label" to use for when referring to the full stack of projects that make up the iOS native app libraries to avoid that confusion?

from architecture.

Perhaps this should be another issue altogether, but commenting here for now as it is related to "community messaging" which I see as the core topic of this thread. I think we should be very thoughtful about how we name/label the individual projects. The broad R2 moniker is already quite problematic (I've seen this play out recently in the industry in many different conversations on multiple continents) and so this is our chance to try to patch that up at least a little. I think we should largely ditch the R2 label on the individual projects. They should instead be very descriptive as to exactly what they are as best possible. Some projects are semi-freestanding modules and should be named as such, and some projects are larger in scope, and fold in multiple modules, and should be differentiated from individual modules. e.g. the "stack" of projects that is designed to be used to create, say, a Native iOS app vs a Go Streamer library that could be used in more than one usecase/enviro. Similarly, overlapping projects should be named in such a way as to attempt to differentiate them. e.g. it could well be that there is a project that contains multiple modules, that as a project targets iOS native apps (with a discreet feature set) and there is another similar project (e.g. the existing one) but that contains different modules, targets different use cases, etc. It would be a problem if those two, seperate projects are perceived as "versions" e.g. V1, V2 if that is not necessarily the case (e.g. a given developer might choose one over due to the various pros/cons and match to their own technical strategies or existing code base.

from architecture.

NYPL is the closest I've seen of being a candidate to implement an "all new" iOS app based on an "all new" stack. I read Winnie's latest technical doc last week, and aside from the "open issues" she identified (e.g. FXL, etc) I'm not clear on whether that document is the current "candidate" as the technical spec. I understand it needs to be accompanied by a 1.0 release functional spec, and the tech spec will need to be more detailed. But my question is: Does that doc represent the current agreement on tech spec among the committed contributors? Seems like this is the first step in preparing guidance for the larger community in terms of the trajectory of the R2 phase projects.

from architecture.

There's quite a lot to address here...

I think a good place to start is mvp target feature set (e.g. what the initial committed implementers will need in order to to ship), then document agreed tech spec/architecture

That's pretty much what we've been doing on the weekly calls, although people have concerns with the acronym "MVP".

That said, I would assume we all agree that R2 certainly won't be a complete and total replacement for R1 iOS SDK or R1 Android SDK in 2017 nor early 2018 so such guidance might assuage the concern if shared?

I wouldn't call R2 an SDK, in fact I have a hard time thinking about R1 as an SDK either.

For me there are two different projects in R1, but not a "full SDK":

• Readium Core SDK (equivalent of the R2 streamer)
• Readium Shared JS (equivalent of "one" R1 navigator)

R2 will have a number of different modules, with multiple implementations for each module.

In its current state, the first module for R2 (streamer) is IMO already reaching a stage where it's as good if not better (metadata, table of contents, media overlay) than Core SDK. It will definitely be a good replacement for the Core SDK as early as mid 2017.

For other modules and implementations, of course the results will vary, but comparing R1 to R2 is really comparing apples to oranges.

I think we should largely ditch the R2 label on the individual projects. [...] Some projects are semi-freestanding modules and should be named as such, and some projects are larger in scope, and fold in multiple modules, and should be differentiated from individual modules. [...] Similarly, overlapping projects should be named in such a way as to attempt to differentiate them.

I disagree about naming. We're doing fine so far with the different projects and there are no overlapping or mixing up of modules.

All three implementations of the streamer will eventually cover the same module and largely behave the same way. No need to add extra confusion by giving them individual names.

We're also starting to work across implementations by using Github issues, documents and tests.

But my question is: Does that doc represent the current agreement on tech spec among the committed contributors?

The doc that you're referring to is meant to express each implementer's take on the navigator module.
This module allows by design a more flexible approach that will differ per platform and depending on the content that you're accessing (ebook, audiobook or comics).

We discuss modules on the weekly call and document technical choices using Markdown documents in the main Readium-2 repo.

from architecture.

My comments here were with a focus/through the lens of the topic of how best to provide information and guidance to "stakeholders" to help them understand the nature of the R2 projects and how that relates to R1 projects. Certainly the engaged teams that attend the weekly meetings are well informed. Though I admit that even I, who sits on the board, discusses these topics at length in face to face meetings with other engaged contributors, and get regular updates on the topics discussed in meetings - find it confusing and unclear at times. I know that there is a perception that I'm "protective" of R1 as my company has invested years of work and 100's of thousands of dollars on R1 and products built on top of it. And of course that is true. However, that is only one of several drivers that leads me to believe that increased clarity in the broader community ("stakeholders" as Laurent put it) would be a good thing. Markdown in a repo is a great and useful thing, but may not be sufficient for such purposes.

from architecture.

Well, this is certainly not limited to Readium-2, the foundation overall could do a better job at communicating what's going on.

For Readium-2 this is still a work in progress but I propose that we do the following:

• provide a high level overview of the projet at https://github.com/orgs/readium/projects/1
• have more discussions on this repo (vs strictly on the weekly call)
• keep track of each implementation at a repo level using Github issues (+ cross repos issues to group some of them together)
• document architecture & decisions on the main repo (Markdown)
• once we reach certain milestones (basically whenever we feel happy about something), publish articles on the Readium & EDRLab websites (with some social media activity too)

This would provide multiple levels of implication:

• if you just want to have a broad idea of what's going on, you can follow the Readium/EDRLab websites and social media accounts
• if you want to have a better idea of what's going on, you can look at the Github project and follow discussions in the main repo issue tracker
• if you want to contribute, you can dig deep into each repo's issue tracker and also read the technical documentation on the main repo

I don't think that a one size fits all solution is possible, that's why such an approach make more sense IMO.

from architecture.

@HadrienGardeur This sounds very good to me. Thanks for summarizing. Trick will be in the doing and maintaining...

from architecture.

I agree with your suggestions in terms of communications, and I think we should take the approach to this that as a community project, we can not rely on "them" (whoever that is) to do this. It is us, the members of the community that need to step up individually to make this happen. I intend to do so myself.

I also agree that one size does not fit all, and discreet strategies for various constituents is effective.

Of course, one of the challenges is that you can only message what you know. And, what people "know" might vary depend on their perspective, and how they want to position that knowledge might vary based on mission, etc. As such, I think that open forums (like discussion threads, social media, individual blogs, etc) are particularly useful venues as they can represent the diversity of thought within the community.

from architecture.

One interesting challenge is the fairly common question I encounter these days, which goes something like this "My organization is planning to build an iOS EPUB3 ereader app with DRM support to ship by EOY. We think Readium is probably the right choice. But should we use Readium 1 or Readium 2?" My current (personal) answer to that is: Well, it is a flaw to even think of that as a choice. Readium 1 is the only option for creating what you describe. Readium 2 is a set of new projects, in various stages (e.g. some are still in an "exploration" phase) that may or may not be useful to you in the near future given your description of your project. It is cool stuff for sure, and you should look at those projects for sure, and heck, if you wanted to contribute to that, fantastic! Oh, and by the way, Readium 2 for iOS native apps my not necessarily be considered "version 2" - e.g. they are in fact "apples and oranges" and if and when the various Readium 2 projects targeting iOS native apps are "complete" it may be that some people choose what we now call Readium 1, or future versions of that, for various tactical/strategic reasons - or not. I just don't know yet. So yea, it is a bit confusing to call it Readium 2, sorry about that. --That is essentially the answer I give currently. I could be totally wrong. But that is currently my best and honest assessment.

from architecture.

To clarify my previous use of the term MVP. I was speaking at bit in shorthand and loosely using that term, but I think it is worth explaining what I meant. My assumption is that, in a project to create an "SDK" for, say, EPUB3 native reading system apps for iOS, one of the early things that needs to happen is that the implementing contributors to the project work towards an agreed-upon scope for the project - e.g. target functional specifications ( in scope/out of scope - something we discussed in the very first few meetings of the nascent Readium Foundation prior to it being a formal org) . And that scope is largely driven by their own internal assessments of functional specifications needed to ship product. Often times looking for commonalities - e.g. some features become considered out of scope as unique to only one implementer, or even if common need, it is agreed that it will vary quite a bit, and therefore should not be part of the "core" project (though could be side projects of a subset of the implementers). So when I'm referring to MVP in my comments above, my intent was to refer to the "in-scope" consensus for the major first phase of a given project. Next step then being coming to consensus on technical specifications/architecture for achieving that scope, then dividing up the effort between the willing contributors (or biting off chunks - if committed contributor resources not yet sufficient to allocate all tasks)

from architecture.

The question about "who" will be doing what I listed above is a good one @BluefireMicah, let me try to summarize it:

• anyone can post issues on the main Readium-2 repo or participate to these discussions
• anyone can participate to our weekly call
• once we have a good starting point, a smaller group of people will usually start drafting a summary document and push it to the repo as a Markdown document (the streamer architecture document is a good example)
• eventually these documents will mature and turn into specifications (Readium Web Publication Manifest being the best example so far)
• in parallel, developers and the project managers that they work with will prototype these ideas and then iterate over them using the issue tracker to list features, enhancements and bugs
• for each module, we'll also try to make sure that we're consistent across platforms by sharing tests and using epics that group together issues across repos (here's the epic for media overlay support in the streamer)
• the Readium-2 Project Board on Github will basically keep track of the progress for these epics and list action items that have been decided during the weekly calls
• finally once we have something to showcase, we'll do more reader-friendly posts on Readium/EDRLab websites and across social media

from architecture.

I think Hadrien has done a lovely job of organizing it. I think the concern is the optics to folks in the community that are weighing their investment in time for R1 vs R2 or adoption of vendor products that use one or the other. While calling this work R2 may cause confusion, that confusion will arise regardless of what you call it because folks will figure out one thing is a different way of doing the same thing the other did but with a different set of priorities. They will ask regardless "Should they use Readium SDK or Readium instead?" Either way simply stating up front what it is and is not as a collection projects and whether they together or in part or combination may or may not form an SDK could be expressed upfront for this phase of the project. It could also be helpful in pointing contribution one way or the other for contributors are going to dig into the repos regardless and chose which project they want. For those not doing the work, then the website (not the wiki) is probably what should guide them.

from architecture.

@jce1028 From an optics standpoint, I do now think that "Readium 2" label was a mistake (a mistake I myself approved of, so casting no blame here at all) and I remain convinced that more granular/descriptive labeling (optically) would be an improvement. Knowing that the <X.0> naming convention comes with a lot of assumptions built in that do not apply here. But I also recognize I'm probably fighting a losing battle trying to get to something more descriptive like "Readium Industrial Windows Can Opener Module in C++" and "Readium Swift iOS Kitchen Collection app project" and "Readium JS elbow compression valve module" rather than, say, Readium 3 and Readium 4 (Hyperbole for illustration). And at the end of the day, it is more like that in Github anyway. It is the more "public" conversations that illustrate deep misunderstanding that I find troublesome, and problematic for both our business and the foundation.

In terms of the process description above by @HadrienGardeur - some good ideas there. I do think that the ideal scenario is that this entire process be primarily driven by implementers. Ideally at least two of them on each project. I see this much in the way that I see specs (e.g. epub) where I think implementers are a critical part of the entire process, and specs that are ratified without sufficient input from, and adoption by implementers can run into, shall we say, challenges. In any case, it is my assumption that as implementers get involved, and communicate to the community what their goals and strategies are, and how the specific projects fit into that, that clarity will emerge fairly organically in any case.

from architecture.

@BluefireMicah I'm not aware of any non-implementer involved in Readium-2 at this point, it would make very little sense to invest time and effort if you're not an implementer

from architecture.

It is worth acknowledging that I come at this from a certain perspective (e.g. a company that makes and sells technology components for the digital publishing industry) that is rather different, than say the perspectives of a content distributor, library, non-profit, etc. Jean-Marie from Mantano, or Kevin from DataLogics are much more likely to relate to my concerns here (in fact I know they do having discussed it at length recently). Not right or wrong, or better or worse, but I think understanding and acknowledging our inherent different points of view and the nature of those are useful in such a diverse community.

from architecture.

@HadrienGardeur I agree, and what I'd love to see is clearer community understanding around how the projects fit into the products being developed by the implementing contributors.

from architecture.

Well I can't speak on behalf of other implementers but in our case at Feedbooks:

• we're using the manifest and navigator design to implement audiobook support in Aldiko, later this will also be useful for comics
• we're completely skipping R1 and will adopt R2 first for LCP protected content on iOS/Android, and switch to R2 for DRM-free once it's on par with RMSDK feature-wise
• parts of R2 are also extremely useful for our ingest process (generating samples, extracting metadata)
• finally we'll also use R2 for a web reading app since its design is great for that (streamer on the server side + JS navigator for the client), could be for reading samples, full books or both

from architecture.

@HadrienGardeur Thanks for sharing. Though I do observe that such description does not in itself, help someone understand what "R2" is - and likely quite the contrary. So perhaps you have proved me wrong - or right - I've no idea which ;-)

Question: you say "will adopt R2 first for LCP protected content on iOS/Android" - do you mean that: some implementers that are targeting building iOS EPUB3 reading apps with DRM support, including your company, have reached consensus on scope of that project, and have reached consensus on technical architecture for all components to be included in that project, have divided up the necessary tasks among the contributors, and you are currently implementing such a product feature for Aldiko and you will be contributing the code that your team writes - that which would naturally be included in the scope of the project?

from architecture.

[...] have reached consensus on scope of that project, and have reached consensus on technical architecture for all components to be included in that project, have divided up the necessary tasks among the contributors

What you're describing is quite the opposite of an agile approach, and we're not doing waterfall-style project management for R2.

For the streamer, we started with a prototype and have been iterating since then. For the Go version, we've reached a point where it's on par or better than Core SDK for most features.

The code (100% written by our team so far) is released under a BSD license and available in a repo at https://github.com/readium/r2-streamer-go

Other implementers have also ported this code and design to other platforms (Swift & Java so far) and released it under a BSD license.
For Java, I know that the devs behind it are working on DRM support using FolioReader as the "navigator" for their app.

For the navigator, we built an initial prototype in JS and NYPL ported/improved that prototype to Typescript for a project. The R2 implementers are not at a point yet where one implementation is leading the way and being iterated over, but hopefully we'll reach that point soon enough.

This is pretty much the definition of being agile and implementer driven.

from architecture.

@HadrienGardeur thanks for that info. I take it as a longer form of "no" - which is just fine, and I agree that this is a very agile approach to creating useful code and I see nothing wrong whatsoever regarding this approach. I would not characterize the approach I myself described as "waterfall" - as an agile software development methodology can certainly be a part of that - as was the case of some of the prior Readium projects. That said, to be clear, I'm glad you are engaged and contributing in this way. This does match my previous understanding of what was going on, so nice to have that validated. It does also confirm to me that Readium 2 is the wrong label for this set of projects. And further convinces me that we need to be very pro-active in terms of communicating the nature of these projects, and what they "are" and "are not" to the the broader stakeholder community.

from architecture.

@HadrienGardeur questions: you said:
"Other implementers have also ported this code and design to other platforms (Swift & Java so far) and released it under a BSD license."
--Can you please share link to these project(s)

"For Java, I know that the devs behind it are working on DRM support using FolioReader as the "navigator" for their app."
--When you say "behind it" what do you mean by "it"?

from architecture.

Stepping back for a moment. If a couple entities come forward next week propsosing a new project, say, a shared component they wish to both use in new products they are making, that they wish to open source, and collaborate with the Readium community on, with some overlap of existing projects, that takes a different technical approach, that addresses different goals and makes different assumption and has a different scope and different process than prior projects, but is deemed useful and potentially valuable by the community. Is that Readium 3? Another R2 project? I think the question is a bit absurd. I think that the numerical progression should be reserved for logical versioning of projects. e.g. where the adopters and contributors view it as a natural evolution of the prior version, expect and assume that most adopters will update to it, and that once complete, the prior version is unlikely to be adopted. Those are not of course hard and fast, nor complete rules for what constitutes the common assumptions and expectations for a Version increment, but I think y'all get my point.

from architecture.

It does also confirm to me that Readium 2 is the wrong label for this set of projects. And further convinces me that we need to be very pro-active in terms of communicating the nature of these projects, and what they "are" and "are not" to the the broader stakeholder community. [...] I think that the numerical progression should be reserved for logical versioning of projects. e.g. where the adopters and contributors view it as a natural evolution of the prior version, expect and assume that most adopters will update to it, and that once complete, the prior version is unlikely to be adopted.

And this is exactly the end goal for R2. The streamer in Go/Swift/Java can definitely replace the Core SDK this year, it'll have better support for metadata in EPUB 2.x & 3.x, better handling of Media Overlay, additional APIs like search, more thoughtful use of HTTP caching and preloading/prerendering, an implementation that can be deployed server-side and a much easier integration path into native projects (goodbye JNI on Android).

Various implementations of the navigator will be exactly the same, it'll just take a few iterations to get there.

Saying that everything needs to be defined and assigned as tasks to various implementers is completely counter intuitive and against an agile project, and sorry but I have a hard time believing that this was truly the case for R1 either.

Can you please share link to these project(s)

All projects are listed on the README of this repo at https://github.com/readium/readium-2

Stepping back for a moment. If a couple entities come forward next week propsosing a new project, say, a shared component they wish to both use in new products they are making, that they wish to open source, and collaborate with the Readium community on, with some overlap of existing projects, that takes a different technical approach, that addresses different goals and makes different assumption and has a different scope and different process than prior projects, but is deemed useful and potentially valuable by the community. Is that Readium 3? Another R2 project? I think the question is a bit absurd.

Well, we'll just talk to them and figure it out.

Some modules in Readium-2 will have a very defined set of technology and design (the streamer comes to mind), but for other modules they're open by design (navigator, pagination).
If it's a different take on the navigator, that still follows the core principles (uses HTTP to get the resources, interacts with either the manifest or in memory model) and main features (display and navigate between resources of the publication), then it can be another take on this specific module.

If it's widely different and doesn't seem like something that makes sense within the wider R2 project, then we can certainly host it too, but under a different name.

from architecture.

I found the naming of Readium-2 confusing without extensive reading.

As a new comer to the Readium group and starting to use Readium, I have been under the impression that Readium-2 is a much better version of Readium that is ready.

Having read through your discussions above, I would say the current name needs to change to save confusion and to reduce the amount of reading/explaining that will be required. Even the description of the repo indicates it is not a version upgrade which makes it even more confusing for someone trying to find the latest version with all the good stuff in it:

A repo for storing documents about Readium-2 modules and discussing the overall architecture of the project.

I think 'Readium Dev' or 'Readium Futures' would be better suited names, for the current repo, as they clearly state that they are not a version upgrade/update but contain elements for possible upgrades/updates which are copied over when ready to 'Readium 2'.

As a result I would expect 'Readium 2' to contain all of 'Readium' plus any released parts of 'Readium Dev' that make 'Readium 2' what it sounds like it is, better :)

from architecture.

It was previous called "Readium Next", a name that @BluefireMicah objected to and agreed to use "Readium-2" instead.

We can call it "Readium Futures" tomorrow and "Readium Native" the day after tomorrow and we'll still hear the same comments, this whole naming argument is IMO futile.

from architecture.

Regrets to be late in this conversation I moved forward. I can't answer to all exchanges, but here is my short take:

The Readium-2 project is not so different from the Readium-1 project when we look at their common objective = create an open-source "reading engine", easy to integrate in a reading app, in different environments. In fine, I believe that Readium-2 will replace Readium SDK and ReadiumJS, and there will be a new version of the Cloud Reader (the only Readium app today) which will use a new JS navigator.
Therefore let's stop discussing the "Readium-2" name, as it was chosen by the Readium board after a long discussion. It's done, and it has a logic.

The set of R2 modules is not so large that nobody can understand it: they are spread along 2 axes:

• type: streamer, navigator, launcher
• language: swift, java, Go, typescript

There may be a third axe: ebook, audiobook, comics -> we would create e.g. a swift-audiobook-navigator, and an app would select the proper navigator depending of the content type streamed by the streamer. @HadrienGardeur is it how you are also thinking?

A given streamer will (IMHO) handle a set of source formats; EPUB 2, 3, 4, PWP, PDF, CDR/CBZ ... integrated iteratively. We must not forget that the W3C Publishing WG is dreaming about having Readium create a reference implementation for PWP and EPUB 4.

There is also this notion of alternative developments for a given module. It is true that before one implementation takes the lead, several prototypes will be created (I'm thinking about pagination here). We could add a suffix to the module name to express that: e.g. swift-ebook-navigator-paged-x. Or more simply use a suffix letter, like swift-ebook-navigator-a.

I agree with having different levels of communication: posts on the EDRLab and Readium websites + tweets , Readium-2 Github repo for functional discussions and technical specs, specific Github repos for each module.

What I'm still missing in this discussion is how to offer a clear view of the iterations applied to each module. The notion of "epic" Hadrien added is great for cross-reference of functionalities, but does not give this evolutive view. We need a notion of evolutive agreed-upon scope for each type of module.
Take the example of a streamer. First, we can open an EPUB 3 and expose its most useful metadata. Then we add the support of the Toc; then the NCX and we can open an EPUB 2. Then font obfuscation. Then media overlays. Then DRM support. Then multiple renditions (do we?).
In order to show a parallel evolution in different languages, we need a notion of version; or a notion of level (as in CSS).
Why not "level 1" (a tag in Github) means "EPUB 3 metadata and resources exposed", "level 2" means "EPUB 3 ToC exposed" etc. ?
It's an extension of the notion of MVP, agile, and easy understandable I think.

from architecture.

note: yeah, I can make my posts veeery long, like Micah ;-)

from architecture.

Yes, I fully have owned up to the fact that I was supportive of "Readium 2" and I was thinking that it was kind of like "Web 2.0" meaning a broader implication of a new "phase". However, the confusion it has generated, which has become clear to me over many different conversations, has led me to believe that using a naming convention that has the baggage of the assumptions of version increments is problematic. It is embarrassing to me to make that case of course, and it is, I know, a pain to change names mid-stream. But I think it is worth it, as, while any naming convention has its pitfalls, using numerical increments in this way is uniquely problematic - I have now come to firmly believe. For that course correction, I apologize.

To be absolutely clear, I think the new projects are great, I'm excited about them and I do not think that the prior tech nor process were inherently superior by any means. I think trying new process approaches and exploring new/alternative technical strategies is great. And the specific projects underway seem extremely promising, useful, and valuable. My sole and only concern I'm trying to address here is clarity and communication within the community and within broader stakeholders circles.

from architecture.

There may be a third axe: ebook, audiobook, comics -> we would create e.g. a swift-audiobook-navigator, and an app would select the proper navigator depending of the content type streamed by the streamer. @HadrienGardeur is it how you are also thinking?

That's exactly the idea @llemeurfr and it'll be up to each app to decide what they implement.

Take the example of a streamer. First, we can open an EPUB 3 and expose its most useful metadata. Then we add the support of the Toc; then the NCX and we can open an EPUB 2. Then font obfuscation. Then media overlays. Then DRM support. Then multiple renditions (do we?).
In order to show a parallel evolution in different languages, we need a notion of version; or a notion of level (as in CSS).
Why not "level 1" (a tag in Github) means "EPUB 3 metadata and resources exposed", "level 2" means "EPUB 3 ToC exposed" etc. ?
It's an extension of the notion of MVP, agile, and easy understandable I think.

During the weekly call, we've already agreed on a "MVP" for the streamer and we're almost there for the navigator too.

I agree that it's a good idea to document that, and if that's what you mean by versioning and roadmap, I think that's a good idea.

from architecture.

@llemeurfr true, but neither of us have the stamina of McCoy!

from architecture.

@BluefireMicah Yes, Bill McCoy is the king of the marathonian text.

from architecture.

should being an operative word, and I'm more concerned with Business Decision Makers than devs. That said, I agree that it is not cut and dry/black and white.

from architecture.

I think there are lots of good thoughts here and not sure it is profitable to try and call out and/or address all of them. Two points:

• I am beginning to agree that names like "Readium Next" and "Readium 2" are somewhat (if not literally) counter-productive in that they do lead to misleading perceptions by some.
• Although there has been lots of progress so far, R2 is far from a product at this stage (hence, some of the reluctance about using a term like MVP). Getting it to a "product" is the application of the old 90/10 rule - the last 10% will take a LOT of time and effort.

My point is that we are projecting a misleading image that we are

• working on a new version
• it will be an equivalent "product" to R1 (SDK and JS) anytime soon.

It's not clear that R2 will ever be a "replacement" for R1. So my feeling is that we SHOULD reconsider the name. Given that our intent (I believe) is to create something that handles not only EPUB2/3, but also comics, audio, PWP content, etc. I think we should come up with a name that suggests that rather than that it is a replacement for R1. Perhaps Readium DCV (Digital Content Viewer). Or "George" or ...

from architecture.

Thank you Ric for your comments. One question, does there really need to be a "singular"name? meaning, it seems to me that there are at least two new projects (not suggesting names here) Readium Streamer, and Readium Navigator. Could it make sense that we don't try to come up with "meta/phase" names, and simply name each logical project and repo?

from architecture.

@BluefireMicah That's an interesting point, but I think it would lead to even more confusion. Those are modules that together form a solution for a need. Now it is entirely conceivable (even likely) that some modules may be used separately, but it seems to me, at least, that we need some sort of label for the effort as a whole.

from architecture.

@BluefireMicah, @rkwright the current issue being about offering a roadmap to the effort, would you consider opening another thread to discuss any re-re-naming of the project?

from architecture.

@llemeurfr Sure.

from architecture.

FYI, during our call today we agreed on a few things:

• we now have the feature list for the first versions of two modules (streamer & navigator)
• each module will have a roadmap document on the repo, providing a bullet list of expected features
• once there's enough documentation for a feature, we'll turn it into an epic to keep track of its development across repos

cc @llemeurfr @rkwright

from architecture.