The future of GeoFS Plugins

[nicolas377]

For those of you that just want to know what's happening to the extension: scroll to the bottom.

We've been modernizing a lot of the code here, and I think that now that we have a lot of features, we're starting to trend away from a 3.4.0 and more towards a 4.0.0, with breaking changes, exposing an API. I think it's time to restart.

We're going to hit the reset button. Everything is going to be deleted, except for the original chrome extension listing, which will be marked as deprecated. Here's a short list of ideas for what would happen while we rebuild:

• rebranding
  • more devs
• change of purpose
  • be a modular extension, exposing an API to add scripts
  • only purpose is to serve as a conveyor belt between addons and geo
  • no default scripts, but links to addons that use the API
• beautiful UI (would be a react app with tailwind)

All those ideas will take quite a while to add, so we could also use a separate extension for release candidates. Also, we will use a new extension, so we can restart versioning from a 0.1.0, and build up slowly until a 1.0.0 release, where everything is ready to be out of beta.

Welcome back, everyone that skipped the technical details! Now that you're back, let me sum this up for you. We will be fixing #145, but after that, we're going to stop supporting the extension. We're going to migrate everything to a new organization, with some new developers, and a new purpose. Once we migrate, we're going to start building a modular extension, built for long term support. We're doing that because we don't want to end up like the older GeoFS Plugins, where people went off to college and life, and things stopped being supported. We want this project to continue long into the future, into when the next generation of GeoFS developers takes over. We want everything to be easier.

[nicolas377]

One thing I forgot, while we're transitioning to the new extension, we should use the (framework) experience we've gotten from the extension to move away from knockout. Knockout is really old, and a lot more unmaintainable than a JSX framework. It's also causing some security notifications that aren't actually vulnerabilities to flare up, which really suck attention away from the development process.

[nicolas377]

One of the things we can do, instead of having to use the tabs permission, is use the chrome.webNavigation API. Here's an example of how to use that.

[Guy-Adler]

using `chrome.webNavigation might be better, although according to this website it produces the same warning. In terms of the scripts, I think we should replace knockout with redux, and also move the UI to react. There would be a global object including all of the scripts' redux stores, to enable passing data between extensions easier.

[nicolas377]

An idea I've had is to have a npm package called create-geofs-plugin that would give other devs a quickstart, basically setting up a whole repo for them to start development of a plugin compatible with the main extension from.

[Guy-Adler]

sounds good

[nicolas377]

Here's the plan I have right now. Please give me feedback on this, since I shouldn't be the only one giving ideas here:

The organization will prune inactive members, (maybe add a new dev, looking for someone that would fit well), and delete this repo. We'll create another repo (open to names) that will host the main extension. That extension will expose a documented API (probably through messages), which other extensions (no ui chrome extensions we'll refer to as plugins) can register scripts to.

We'll maintain an npm package, create-geofs-plugin, that would be somewhat like create-react-app in that it only registers a script run via npx. It would clear the working dir, and replace it with everything needed to create a chrome extension that can register a plugin.

The main extension won't have any plugins by default. However, the organization will also have a more repos that have the source code for some plugins. Each plugin will get its own repo, and be generated from create-geofs-plugin package. We'll use redux for plugins that don't have a UI in GeoFS, and react for those that do.

For all of our UI's, we'll use tailwindcss. There might be a better framework, but tailwind is the one I'm familiar with, and it seems like a good solution for our use cases.

[Guy-Adler]

Sounds good, although I think plugins with UI should both redux and react, for the communication between plugins to be standardized. When saying "no ui chrome extensions we'll refer to as plugins", are you thinking of actual chrome extensions or just content scripts (like, say, the original ap++)?

[nicolas377]

I'm thinking that the user installs a plugin chrome extension, it doesn't do anything besides register a script that it hosts with the main extension. The extension will take care of the injecting, and UI, and it'll provide links to the scripts for bug reports/feature requests, the like.

[Guy-Adler]

I think the chrome web store developer fee will repel many developers, and providing some way to host scripts (either on the extension itself or just as a link to a released script in a GitHub repo) and injecting them (we can just link the script tags to external URLs) via the main extension is a better and simpler way to do it.

[nicolas377]

I think adding scripts through a link to a .json file that has the needed info would be a good idea.