[PR #4598] [CLOSED] Dynamic loading of shared code in Plugins. (Design concept) #10005

New issue

Closed

opened 2025-12-22 07:47:49 +01:00 by backuprepo · 0 comments

backuprepo commented

2025-12-22 07:47:49 +01:00

Owner

📋 Pull Request Information

Original PR: https://github.com/jellyfin/jellyfin/pull/4598
Author: @BaronGreenback
Created: 11/27/2020
Status: ❌ Closed

Base: master ← Head: DesignConcept

📝 Commits (10+)

dc1cec9 Merge pull request #98 from jellyfin/master
4b35265 Create random
4729999 Add files via upload
bab914c Add files via upload
21edbd2 Update Transmute.cs
459f7ab Update SharedCodeManager.cs
dbb415f Delete random
a06a7e8 Update PluginRegistrarExample.cs
a935869 Update SampleSharedCodeExample.cs
a8fe948 Update SharedCodeManager.cs

📊 Changes

5 files changed (+203 additions, -0 deletions)

View changed files

➕ DesignConcept/PluginRegistrarExample.cs (+30 -0)
➕ DesignConcept/SampleSharedCodeExample.cs (+21 -0)
➕ DesignConcept/SharedCodeAttribute.cs (+20 -0)
➕ DesignConcept/SharedCodeManager.cs (+95 -0)
➕ DesignConcept/Transmute.cs (+37 -0)

📄 Description

This is NOT valid code - just a possible concept. Don't yet know if it will work this way, but don't want to develop the concept futher until there is some agreement about whether this is the direction to go. There may be a better solution.

Issue.
Two plugins use the same code. Normally this could be done by reproducing the same code in each plugin, but in this instance, the code in question consumes the same system resource. (The shared code manages this - that's why it's, well, shared!)

Possible solutions

Leave the code in the JF codebase
This is a possibility in this instance, however, do we want plugin code hanging around in the core? And how would 3rd party developers do this?

This concept

The shared code is placed into a separate dll in a sub-folder of the plugin (eg. /common/) so that it isn't automatically loaded at runtime.
Each plugin calls a system function that checks to see if the interface type has already been registered in the DI.
If it hasn't then the dll is loaded and registers the "shared" types in DI for use throughout the system.
The system then transmutes the interfaces in the plugin, so that they point to the shared code version.

This would seem to enable either / or / none to be loaded and registered / shared dynamically.

Some sample code (again - not compiled) is included to give a gist of what i mean is attached.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/jellyfin/jellyfin/pull/4598 **Author:** [@BaronGreenback](https://github.com/BaronGreenback) **Created:** 11/27/2020 **Status:** ❌ Closed **Base:** `master` ← **Head:** `DesignConcept` --- ### 📝 Commits (10+) - [`dc1cec9`](https://github.com/jellyfin/jellyfin/commit/dc1cec9fd82af8742cf2b20f2da1fdf1de6bd41d) Merge pull request #98 from jellyfin/master - [`4b35265`](https://github.com/jellyfin/jellyfin/commit/4b35265c8398a2335b2bd64ab10bf1479451638d) Create random - [`4729999`](https://github.com/jellyfin/jellyfin/commit/4729999bcd156259d7185e0a130aa820a29831e6) Add files via upload - [`bab914c`](https://github.com/jellyfin/jellyfin/commit/bab914c7087eb7aa87e69ddf0c0eca15bd843ae7) Add files via upload - [`21edbd2`](https://github.com/jellyfin/jellyfin/commit/21edbd26120e5fd2c623e7820ed98fcb6a4ffd81) Update Transmute.cs - [`459f7ab`](https://github.com/jellyfin/jellyfin/commit/459f7abf75aa6cea9e10dc96ab9e295e76742998) Update SharedCodeManager.cs - [`dbb415f`](https://github.com/jellyfin/jellyfin/commit/dbb415f536732fce69de8ccb93d7b337f04f7611) Delete random - [`a06a7e8`](https://github.com/jellyfin/jellyfin/commit/a06a7e8a7f8b337e2b6db44e8518a394108ecf95) Update PluginRegistrarExample.cs - [`a935869`](https://github.com/jellyfin/jellyfin/commit/a935869abd6631fa39de03179bb9880523deb4d7) Update SampleSharedCodeExample.cs - [`a8fe948`](https://github.com/jellyfin/jellyfin/commit/a8fe9480009aa9c122340074429c9ab7e567c994) Update SharedCodeManager.cs ### 📊 Changes **5 files changed** (+203 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `DesignConcept/PluginRegistrarExample.cs` (+30 -0) ➕ `DesignConcept/SampleSharedCodeExample.cs` (+21 -0) ➕ `DesignConcept/SharedCodeAttribute.cs` (+20 -0) ➕ `DesignConcept/SharedCodeManager.cs` (+95 -0) ➕ `DesignConcept/Transmute.cs` (+37 -0) </details> ### 📄 Description **This is NOT valid code - just a possible concept.** Don't yet know if it will work this way, but don't want to develop the concept futher until there is some agreement about whether this is the direction to go. There may be a better solution. **Issue.** Two plugins use the same code. Normally this could be done by reproducing the same code in each plugin, but in this instance, the code in question **consumes the same system resource.** (The shared code manages this - that's why it's, well, shared!) **Possible solutions** **Leave the code in the JF codebase** This is a possibility in this instance, however, do we want plugin code hanging around in the core? And how would 3rd party developers do this? **This concept** 1. The shared code is placed into a separate dll in a sub-folder of the plugin (eg. /common/) so that it isn't automatically loaded at runtime. 2. Each plugin calls a system function that checks to see if the interface type has already been registered in the DI. If it hasn't then the dll is loaded and registers the "shared" types in DI for use throughout the system. 3. The system then transmutes the interfaces in the plugin, so that they point to the shared code version. This would seem to enable either / or / none to be loaded and registered / shared dynamically. Some sample code (again - not compiled) is included to give a gist of what i mean is attached. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

backuprepo

2025-12-22 07:47:49 +01:00

closed this issue
added the
pull-request
label

backuprepo referenced this issue

2025-12-22 09:07:57 +01:00

[PR #10051] [MERGED] Refactor URI overrides #12140

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#10005

No description provided.

Rows
Columns