search

meebey / smuxi

Smuxi is an user-friendly and free IRC client for Linux, Windows and Mac OS X based on GNOME / GTK+
https://smuxi.im/
GNU General Public License v2.0
174 stars 46 forks source link

Core/Engines: migrate to MonoAddins infrastructure #246

Open knocte opened 8 years ago

knocte commented 8 years ago

Only for the backend for now. (TODO: Load frontends with mono-addins too.) This integration work opens the door for more add-in management love, such as loading/unloading capabilities at runtime, installing/updating add-ins from remote repositories (via Cydin[1]), etc.

[1] https://github.com/slluis/cydin

meebey commented 8 years ago

When I wrote the plugin loader of Smuxi, Mono.Addins didn't exist, but I checked a few times how Mono.Addins could enhance Smuxi but never reached the conclusion of the pros outweigh the cons.

knocte commented 8 years ago

I guess one of the cons was "I have to invest time doing it", now you don't :)

I wrote my pros in the commit message.

knocte commented 8 years ago

PS: When we have discussed this in the past, you always only said that Mono.Addins didn't exist, never heard your cons ;-)

meebey commented 8 years ago

Cons:

Pros:

meebey commented 8 years ago

Not sure what to think about Mono.Addins when it comes to Smuxi's hook system as it is a completely different approach.

meebey commented 8 years ago

An update system is pretty important for Smuxi (on Windows and OS X) but I doubt Mono.Addins is the right approach for that.

meebey commented 8 years ago

One area where Mono.Addins could fix some big mess is the internal command API of Smuxi, see https://smuxi.im/issues/show/768

knocte commented 8 years ago

new external dependency (this is an disadvantage when having to ship bugfixes)

Sure, but this is a meta-con, as in, it's obvious in general that bringing a dependency is bad, if the pros don't outweigh it.

over the years I have seen DB issues of Mono.Addins that prevents the application (e.g. Banshee and MonoDevelop)

Only seen in Banshee myself, never in MonoDevelop. From the 2 I saw, one of them I fixed it myself in mono-addins, the other one was less frequent and stopped happening (I guess thanks to new versions).

Not sure what to think about Mono.Addins when it comes to Smuxi's hook system as it is a completely different approach.

Well, the hook system doesn't map to the monoaddins infrastructure but would still work. AFAIU you cannot really do much with hooks anyway (you cannot develop a new protocol engine with them, right?).

An update system is pretty important for Smuxi (on Windows and OS X) but I doubt Mono.Addins is the right approach for that.

I completely understand that argument coming from a DD :) I guess you could always disable the update-features of MonoAddins in the Linux version (so that only blessed updates come from the distro), however, developing a proper update system for Winodws/OSX takes time and effort (a would approach would be Squirrel I guess), so we could have this in the meantime (if the core is maintained relatively stable for new versions of plugins to still work on old versions of the AddinRoot; and I grasp that backwards compatibility is already a thing you care about ;-) ).

refactor Smuxi's engine plugin loader code (done by @knocte)

Why do you list that as a con? ;)

refactor Smuxi's frontend plugin loader code

I didn't do that yet because I wanted early feedback first. If I get green light I'll work on the frontend side, which shouldn't be much harder than the backend side (at least the basic migration).

meebey commented 8 years ago

refactor Smuxi's engine plugin loader code (done by @knocte) Why do you list that as a con? ;)

Markdown has no strike through, I will edit to make that clearer

knocte commented 3 years ago

@meebey ping, this is ready! also green in Travis: https://travis-ci.org/github/meebey/smuxi

As you removed old mono version support, then this PR doesn't break CI anymore hehe