Upgrade Flarum from within Bazaar

[luceos]

In light of the namespace changes for beta 8 I had a little brainstorm with @clarkwinkelmann and @cdk2020 about a strategy to upgrade.

• [ ] We will add an upgrade button to the Bazaar header menu in case a new version of Flarum is out.
• [ ] Flagrow.io will report whether a new flarum version is out either via another header or via the meta information on each request.
• [ ] We will implement full separated calls to Flagrow.io, instead of doing one request for all extensions we will use pagination and filtering completely. This will allow us to stop filtering the payload based on the Flarum version from the flagrow.io side and do it from within Bazaar.
• [ ] We will add information to extension payload (serializer) that this package (its latest version) is (possibly) not compatible with the current Flarum version. We add comparable information to the payload for extensions that are not compatible with the new Flarum release.
• [ ] Using the upgrade button a modal will popup listing all installed extensions not compatible with the new version and a button to uninstall or disable these. When everything is okay the modal will show an upgrade button.

This issue has the form of an epic and possibly needs splitting up into smaller tasks aka user stories.

[clarkwinkelmann]

In order to reduce the flagrow.io payload, we could also switch to pointer-based pagination, where we only get extensions that changed since the last request.

It does not really help to solve the update issue, but would allow us to return all extensions (whether compatible or not, or will-be-incompatible) without using a massive amount of bandwidth (and the required processing) on Bazaar end.

[luceos]

So, never having heard of pointer based systems. The implementation would be like a salt. Whenever Bazaar calls on flagrow.io it would also send along the array of package names and salts so that flagrow.io can identify the updates required. If this is correct;

• why bother with a salt, simply send the package version?
• wouldn't the payload become too big for a GET request?
• this reduces the need for regular package syncing

[clarkwinkelmann]

@luceos not sure how it works, but when you browse files on Dropbox (API doc https://www.dropbox.com/developers/documentation/http/documentation#files-list_folder-continue), each request returns a cursor. You then use that cursor for the next request and you get the new changes.

I don't know if they maintain a list of all opened cursor on Dropbox end, or if the cursor contains the information itself. Simply embedding the filter and a timestamp in the cursor should be enough to let the remote server know where it needs to continue from.