[server] Remove the HTTP server (like in Bookari)

[jmgeffroy]

Removing the HTTP server has a lot of positive consequences:

• The contents is no longer accessible to other apps
• Requests responses are no longer serialized, and this provides a huge boost in performances (99% of the time is spent in this serialization, according to recent profiling).

This performance boost can easily be perceived when navigating with the ToC or progressbar in a book which contains its own fonts, or many image assets. In this area:

• Google Play Books, Kindle, Colibrio, Moon Reader, FB Reader and Bookari are extremely fast in this use-case. Most of them don't use the same technology as Readium and Iridium do (webviews+HTTP servers), however. But Bookari does rely on WebViews. Bookari only starts a HTTP server if the device is running Android < API level 24:
  • On android 4.x because the WebResource API did not exist
  • On Android 5 and 6 because audio files are not read
• Readium, Iridium, and other Readium-based apps have strong performance issues there.

For Iridium, we don't need to take care of Android <= 6, but we'll maintain the ability to start the HTTP server for different usages, such as client-server deployments (some adaptations will be required for his use-case but are worth investigating).

Thanks to the migration to Flutter InAppWebView, we have everything we need: https://pub.dev/documentation/flutter_inappwebview/latest/flutter_inappwebview/WebView/onLoadResourceCustomScheme.html

onLoadResourceCustomScheme is an InAppWebView cross-platform option, so it should be OK on both Android and iOS...

Note: See in Bookari (Mantano private repo)

• EpubWebViewClient.shouldInterceptRequest
• Epub3WebViewFragment.mustRunServer

See also:

• iOS: https://github.com/pichillilorenzo/flutter_inappwebview/issues/675#issuecomment-776187909
• Android-specific shouldInterceptRequest in https://pub.dev/packages/flutter_inappwebview/example
• Issue in R2 Kotlin
• Issue in R2 iOS

[jmgeffroy]

First tests are disappointing from a performance point of view. The reason is that "you shouldn't do any heavy processing inside shouldInterceptRequest, as it is a synchronous call (albeit on another thread). Calls for all network requests are processed on the same thread so blocking for one request will cause all of the other requests to be blocked as well" (source). So we should spawn isolates.

[jmgeffroy]

Putting this on hold, and implementing isolates in the server version

[westernbuptboy]

note and bookmark not work on Android 6 because paginationInfo and currentSpineItemContext is null. related to this issue?

[gwangbaekun]

Yes. related. Bloc doesn't add data anymore. You should manually set paginationInfo with the position.