Ferdium app / Server interaction

[SpecialAro]

Hello all!

I'm opening this discussing because this is a major issue that we need to tackle that might (will, most likely) have BREAKING CHANGES on the upcoming versions of Ferdium.

Briefing

As stated in #224, there is currently a major issue on the Ferdium-app and server interaction on what regards recipes. This issue affects only users with an account connected to any API (meaning that accountless users aren't affect by this).

The problem

Ferdium checks the API server for a new "signal" on whether there is a recipe new version or not. And then, instead of downloading the new version from the API server, it checks the local instance for a version mismatch again, and triggers an install of that version (local) again. And then, after reload, it checks again for updates and the cycle starts again....

As stated before, if you use the local server as an API (i.e. without an account) then this issue doesn't happen given the fact that the local server doesn't receive the version bump until you install a new Ferdium version.

I think the idea behind this was that the App should download from the server the latest recipe version. Although, there is a catch on that - sometimes recipes changes are also accompanied with an app change (i.e. a change done to Ferdium-App and also to Ferdium-Recipes at the same time, making the recipe dependent on functions exported as global on the app), which causes problems.
Therefore, this issue needs a full review of the App - Recipe - Server integration process and that some rules need to be defined so that users can't have a problem with this.

Proposed solution

@vraravam pointed out that:

On the app, we will have to send both the recipe version as well as the app version. On the server, the server should know what's the latest version of the app that has been released (now this brings in further complication whether to support nightlies/betas as well as public versions). On top of this, the recipe version should be checked for the compatible version of the app vs recipe combination.

Solution 1

We can expose at the server side the lastest working version of the app itself, which would be checked by the Ferdium-app before checking for recipes updates.
Then, if the user is running a version which is >= server exposed then it should go to the recipe upgrade feature (1). Otherwise, it won't check for recipe upgrades, and it would stick with whatever version of the recipe the internal server has until the user upgrades the app.

(1) In here we would still face the problem where the internal server will be running a latter version when compared to the API server, but this time, given that the recipe's version is higher, it won't force an update.

Solution 2

Quoting @vraravam:

A simpler solution would be that we do not allow recipe upgrades on the server. Instead force the user to upgrade the app. This has downsides where users who dont want to upgrade to nightlies, but demand recipe fixes will keep logging bugs - for which we will end up responding "go to nightly or wait for a new version". imo, this is a catch-22 that we need to take a decision on either side and stick with it.

Solution 3

Having three different servers connected with a shared database (we use sqlite, and I'm not entirely sure if the 3 servers can work together accessing and changing a single file at the same time). This solution may be a little overkill.

Solution 4

Stick with what he have, but disable the API server for pre-releases (beta and nightlies), only having it running for stable releases - meaning that the server will only be updated once a stable release takes place. This solution has several downsides, being the major one that we're limiting the possibilities of usage and test of "unstable" versions with possible improvements on recipes for general users (which will, of course, limit their feedback on the nightly/beta stage).

Intended outcomes

By opening this discussion I intend to find a solution that better fits us (there can be more ideas out there, please, bring them in!), within an appropriate time frame - possibly before a new beta/stable release, so that users won't face this major issue.

Thank you all!

[kris7t]

there is a catch on that - sometimes recipes changes are also accompanied with an app change (i.e. a change done to Ferdium-App and also to Ferdium-Recipes at the same time, making the recipe dependent on functions exported as global on the app), which causes problems.

In principle, this could be handled by recipes indicating the (minimum) version of the application they are compatible with. This can be done either by

• simply indicating the minimum Ferdium version in the recipe json, or
• indicating a recipe API version (like recipe manifest 1, 2, 3, ... analogously to e.g., webextension manifest version) in the recipe version.
  when checking for recipe updates, the client can just download and upgrade the recipe if its is compatible with its version (or recipe API version). If the new version is incompatible with the client, we can show a (dismissable) notification that a recipe update is available, but needs an application upgrade.

This is just a twist on Solution 1, but instead of blocking recipe updates altogether, it'd only block updates to recipes that rely on the new API. So care should be taken not to bump the required Ferdium version / recipe API version in a recipe unless the new API is actually needed.

[vraravam]

If/when we implement this, then there will be a disconnect between what's supported by the other servers (Franz, Ferdi, etc) - we will need to watch out for how that erratic behavior is minimized for the end user.