Skip to content

Commit

Permalink
First pass at the blog post.
Browse files Browse the repository at this point in the history
  • Loading branch information
John-LittleBearLabs committed Jul 31, 2024
1 parent a10cfd1 commit dfe21eb
Showing 1 changed file with 6 additions and 2 deletions.
8 changes: 6 additions & 2 deletions doc/spin_blog.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ It is also very, very active with code changes happening nearly constantly, and

This leaves a number of projects in the sometimes-hairy situation of being "downstream", defining their code as a series of patches, file additions, and/or file deletions on top of Chromium's code base. And of course this means a fair amount of work needs to be done to accomodate upstream changes. Electron is in this camp, and as a very active project in its own right they do an excellent job of it.

So what if someone wanted a slightly modified Electron, perhaps adding some feature(s) that are too specific to be in-scope for upstream -- creating their own flavor of Electron? They need to ask themselves a very serious question: are they really going to maintain a project that is a set of patches on top of a rapidly-moving set of patches on top of a rapidly-moving upstream? How difficult is this? Could we make it easier?
So what if someone wanted a slightly modified Electron, perhaps adding some feature(s) that are too specific to be in-scope for upstream, but make sense for their specific application? Create their own flavor of Electron? They need to ask themselves a very serious question: are they really going to maintain a project that is a set of patches on top of a rapidly-moving set of patches on top of a rapidly-moving upstream? How difficult is this? Could we make it easier?

## One approach

Expand All @@ -22,7 +22,7 @@ So, on the downstream side this means:
* Add a directory for your module, complete with it's own BUILD.gn
* Include a source file (header) with a pre-defined name that implements a pre-defined function signature, for each hook you want to use.

On the upstream (electron) side, this means:
On the [upstream](https://github.com/little-bear-labs/ipfs-electron/pull/2) (electron) side, this means:
* The build script notes the presence of your BUILD.gn and adds a dependency so it can call into your code
* For each pre-defined header file name, if it exists the build script flips a build flag
* In the appropriate part of the build, if the compile-time flag is set, it includes your header and compiles a call into your function.
Expand Down Expand Up @@ -57,3 +57,7 @@ electron tweak replaces uses a sub-resources URL Loader to intercept requests fr
#### IPFS

[This](https://github.com/little-bear-labs/ipfs-chromium/pull/107/files#diff-e390c84b9e1ba2826cd2ce771bedc81b9d5a65fc95f134403fd141f864137b4b) variant of electron uses all 5 of the above hooks and fully supports `ipfs://` and `ipns://` URLs.

## Feedback

What use-case-specific functionality would you like your app to have? What do you think about this approach? Don't be afraid to join [the conversation](https://github.com/electron/electron/issues/42455).

0 comments on commit dfe21eb

Please sign in to comment.