Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thinking of Module vs Plugin #2

Open
John0King opened this issue Apr 12, 2021 · 0 comments
Open

Thinking of Module vs Plugin #2

John0King opened this issue Apr 12, 2021 · 0 comments

Comments

@John0King
Copy link
Owner

John0King commented Apr 12, 2021

modularization mains:

  1. cold module load
  2. module can call each other
  3. module may cause host app crash
  4. module is static for the app
  5. module may need isolation ( data and service isolation, not Type/Assembly isolation )

plugin mains:

  1. cold plugin load
  2. cold plugin unload
  3. hot plugin load
  4. hot plugin unload
  5. must need Type/Assembly isolation
  6. plugin may need to call each other
  7. plugin may need to modify the parent plugin host app.
  8. plugin must not cause host app crash! (the plugin itself can crash)
  9. plugin is dynamic for the app

problems

  1. hot plugin unload is limited (emit stuff can not be used)
  2. assembly isolation is hard : while we need some framework type in the plugin's host app (a framework type may not in the host app or a framework.extensions type is inside a plugin too [consider of , self-contained, different runtime (desktop runtime, server runtime and .net 6 introduce an assembly missing that is System.Drawing.Common) ])
  3. Plugin call each other has the same problem like problem 2
  4. A type shared across host app and plugin , then it can not be isolated to it's child plugin.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant