Removing Plugins

[distantcam]

trafficstars

Does anyone have objections if I remove the plugins?

I'll fold the only plugin we have into the main code.

I don't like plugins because:

• The plugin API has to be versioned. This is a pain, especially if you want to support backwards compatibility.
• Plugins are either run in the same app-domain, or in their own app-domain so as to not cause the whole app to crash. In either case handling a crashing plugin needs work.
• When a plugin crashes, the main app gets blamed.
• How are plugins installed? If we're using clickonce how would that work?

Thoughs? @JakeGinnivan @shiftkey

[JakeGinnivan]

Yeah, happy to drop them. I still like separation of concerns etc, so we can still have IEnumerable<IRenderTransformer> etc, but not as a plugin model

[distantcam]

I still like separation of concerns etc, so we can still have IEnumerable<IRenderTransformer> etc, but not as a plugin model

Why? Separation of concerns is nice and all, but why add it to the render transforms? How do you handle order and dependencies?

Again, KISS and avoid unnecessary complexity.

[JakeGinnivan]

Doesn't have to be that abstraction.

I'm just saying it was a bitch pulling the DocumentViewModel apart because it had the entire applications logic in it. Happy for them to be moved into application services or something

[shiftkey]

I'll fold the only plugin we have into the main code.

:+1:

If it's unused code or abstractions, let's kill it off.

I'm just saying it was a bitch pulling the DocumentViewModel apart because it had the entire applications logic in it. Happy for them to be moved into application services or something

Is this worth a separate discussion?