Which modules will be in a (cross-platform) script language? about architecture HOT 8 CLOSED

One comment I have about TypeScript is a concern about how 'typings' are required for the non-typescript javascript modules that npm installs as a part of Readium.js

I am not suggesting that we not use TypeScript, only voicing a concern and hopefully starting a conversation.

I have found that many npm modules require typings to be used with a TypeScript project and that these definitions are often missing or created by parties other than those responsible of the original module. This leads to version conflicts or bad or missing definitions which is problematic as it causes a build failure when attempting compilation.

Is anyone else concerned about this? Do we have a strategy for this issue. Or manybe it is not a concern and I can learn something.

from architecture.

Well, assuming a total codebase rewrite, and therefore a migration from Readium-1's current build system (which ; despite the rather convoluted NodeJS scripts that drive the submodule integration ; essentially boils down to simple AMD + RequireJS optimizer / bundler) to a more sophisticated TypeScript / Babel setup (language transpiler + module bundler): then, ancillary code dependencies ; such as NPM packages defined outside of Readium's source tree ; should indeed include type definitions, to ensure a smooth and uncluttered build process (or you say, to prevent outright build failure).

However, the emerging pragmatic consensus is that incremental refactoring is the only viable path forward, given the current development resources. This would indeed allow existing contributors to address Readium-1's shortcomings within a realistic timeframe, and in the longer-term to encourage wider open-source participation. In this case, any TypeScript-defined components ; such as the proposed "publication fetcher + resource pre-processor + content parser" ; would need to be adapted in order to fit within Readium-1's build infrastructure. This would mean wrapping the transpiled Javascript components (probably originally organised as CommonJS or other kind module definition) with AMD signatures.

Note that regardless of the programming language and build system used, integrating new "publication fetcher + resource pre-processor + content parser" functionality into Readium-1 will be a non-trivial architectural task. We already talked about eliminating redundant data models, and we mentioned the need to harmonize the asynchronous methods used to access publication resources (abstraction layers for content streams, filesystem, packed EPUBs, online assets, etc.). Ideally, ReadiumSDK and native "launcher" apps would continue to work without any significant code changes, thanks to the minimal readium-shared-js interface, and the interchange JSON format used to pass publication data. However the repercussions on ReadiumJS apps (such as the cloud reader / Chrome app) would naturally be more substantial.

In closing, I think that a TypeScript "pilot" project focusing only on core "fetcher + pre-processor + parser" functionality would be beneficial on multiple levels. This could become a blueprint for future Readium API/component development, with a required emphasis on continuous integration and automated tests. This would promote Javascript as a default, portable implementation (client and server side, desktop and mobile hybrid apps, and of course browser-based apps / SDKs). Concrete implementations for specific platforms (e.g. Java for Android, Swift for iOS, etc.) could also be contributed, for example as alternative to parts of the C++ ReadiumSDK that are hard to integrate and/or costly to maintain (JNI and RDServices, I'm looking at you ;)

from architecture.

TypeScript 2.0 added shorthand ambient module declarations which is supposed to make it easier to use modules without typings. If you can't find good typings for a module and don't want to write them yourself, you just say declare module "foo"; and it will treat the entire module as type any.

from architecture.

Thank you for the replies. I agree, Daniel, with the approach you have outlined in your last paragraph. A pilot project that is free from the tethers of integrating into the current Readium.js-1 would be much more valuable, in my opinion, as reading systems are evolving into open-web, browser-based solutions that make use of web services for publication fetching instead of a zip archive format. I think that the pilot project you mention should be the underpinnings of a project that addresses just that.

And thank you, Amy for you suggestion regarding my typings concern; I will take a look at ambient module declarations.

from architecture.

In closing, I think that a TypeScript "pilot" project focusing only on core "fetcher + pre-processor + parser" functionality would be beneficial on multiple levels. This could become a blueprint for future Readium API/component development, with a required emphasis on continuous integration and automated tests. This would promote Javascript as a default, portable implementation (client and server side, desktop and mobile hybrid apps, and of course browser-based apps / SDKs). Concrete implementations for specific platforms (e.g. Java for Android, Swift for iOS, etc.) could also be contributed, for example as alternative to parts of the C++ ReadiumSDK that are hard to integrate and/or costly to maintain (JNI and RDServices, I'm looking at you ;)

I'm going to repeat myself (already said something similar in #20) but this feels like a weird choice for our first priority.

Since Readium-2 prioritizes mobile apps over the web app, it's a strange decision to start our efforts by developing something that won't be used by mobile apps on iOS/Android.
I know that people are excited about potentially using Typescript, but in our discussions so far we haven't really made good progress on the JS part, or more precisely which modules we absolutely expect to be written in JS.

I mostly agree with what the first steps for the project should be (focus on parser, JSON manifest & HTTP server), but it feels like Readium-1 all over again if we actually start with the Web App use case before the mobile one.

I'm also not sold on the server side benefits of this, I would much rather use Go-lang for it, and I know that other companies involved in this effort would rather use Python, Ruby or Java. With the push towards Swift on the server and Java still being a very popular choice for back-end development, I could argue that starting with either iOS (Swift) or Android (Java) brings pretty much the same benefits.

from architecture.

Let's not be confused, and please let's separate the notion of using JS/Typescript with the notion of targeting a Cloud Reader or not.
We are not targeting a Cloud Reader in this phase -> This is not doing R1 Cloud Reader again.
We need a simple reference language of interface definition.
Typescript can be used as a simple reference language of interface definition.
iOS, Android, Go, PHP ... implementations can be made in quasi-parallel
The EDRLab Electron based desktop prototype is based of JS, and it needs a parser; a Typescript/JS based parser will be very useful for the app.

Note: EDRLab will be happy to participate to the Typescript and Android implementations of this parser (I have to check with Daniel about iOS).

from architecture.

If we start by doing the parser in JS, we're not putting mobile first, instead we focus on desktop which goes against the principles that we've established for R2.

I'm not saying that we should not do it at all, but doing it first is a very strange choice and sounds far away from our official position (mobile & agile).

from architecture.

to avoid xross-posting:
#20 (comment)

from architecture.