In the first SoapBox Core article I ever read on codeproject Scott said, “Currently SoapBox Core doesn’t have a mechanism to add new extensions during execution, but it will eventually”. Ever since I read that I have been intrigued by the idea but with two nagging questions:

  1. How would such a thing be implemented?
  2. What good would it do? Could such a mechanism help me implement new functionality, or implement old functionality more easily? If so, how?

I think I have a vague idea what I would say to (1.) is forced to give an answer, but I am still pretty much in the dark about (2). I understand that not having to restart an application after adding a new add-in is nice, but to me it is not that huge of a deal. I am hoping that someone can think of something a bit cooler that could be done with a mechanism that allows for arbitrary dynamic recomposes.

Any ideas?

asked 19 Oct '10, 22:41

KarlB's gravatar image

accept rate: 0%

edited 21 Oct '10, 20:23

Scott%20Whitlock's gravatar image

Scott Whitlock ♦♦

Yeah, we desperately need an Add-in manager

(21 Oct '10, 13:01) Scott Whitlock ♦♦

I have planned from the beginning to build an add-in manager for SoapBox Core. That's why you see a lot of AllowRecomposition flags set on many imports in the code. Here's what I envision, though I welcome everyone's input:

  • By default, we import all add-ins in the host's directory, just like we do now. Every add-in in the root directory is considered to be part of your main application, so that makes sense. They're mandatory.
  • We need an AddIn subfolder where we download new "optional" add-ins to.
  • Each downloaded (or bundled) add-in should go in it's own subfolder under the AddIn folder.
  • The AddInManager (which is itself a "mandatory" add-in that you can choose to include in your application's build) will have an extension point for AddInSources
  • An IAddInSource is just an abstract interface to a service that can go query, list, and download add-ins from some repository. We can provide some base classes to build your own, like one that will just look for add-ins on an FTP site, or at a web site, etc. You can also roll your own from scratch.
  • When we look at what comprises an "optional" add-in, I think we're talking about a collection of extensions across various DLLs, plus some kind of Manifest with meta information about the add-in. I would prefer not to use a separate manifest file for this. If we could define an IAddIn and use metadata to find it and determine whether to load it, I think that's cleaner.
  • We should be able to load new add-ins during execution (hence the AllowRecomposition flags) but MEF won't allow us to unload (because all add-ins run in the same app domain). We need to provide some kind of "disabling" feature when the user chooses to "unload" one. We'll unfortunately have to leave it up to the add-in author to do the right think and play by the rules though.



answered 21 Oct '10, 20:38

Scott%20Whitlock's gravatar image

Scott Whitlock ♦♦
accept rate: 50%

From other feature requests: we need a way for the main application to filter what add-ins the user can see, depending on rights, etc.

(21 Oct '10, 20:41) Scott Whitlock ♦♦

From other feature requests: where could we host a repository of shared add-ins? How would this work? Would it become an "app store"?

(21 Oct '10, 20:43) Scott Whitlock ♦♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: 19 Oct '10, 22:41

Seen: 2,215 times

Last updated: 21 Oct '10, 20:43

powered by OSQA