Overview

​Mono is a Open Source implementation of the .NET runtime. The Mono Loader aims to embed mono into libpurple so that plugins can be written in any .NET Language.

Mono Loader SoC Development Notes

The Final Stretch

• Finish wrapping up signals and individual modules (using mono-generate-signal, and mono-generate-class).
• Unregister all delegates (and the signal marshall if no delegates left) that belong to a plugin.
• Allow a plugin to selectively unregister a signal.

SoC Goals and Milestones

• Completely wrap libpurple API in .NET bindings.
• Fix the Mysterious Seg Fault On Exit (tm).
• Re-examing and possibly re-implement signal-glue and API -glue code. The glue code is now gone. The use of DllImport has made it all pretty much obsolete.
• Give .NET Purple objects the ability to actually update their C counterpart (or create one).
• Would be nice if we could explicitly state what Delegates expect, e.g. OnBuddyStatusChanged(Buddy b, Status s) . Possible solution is to pass Event an array of Types. Then Signal.connect registers its own handler. When that gets invoked it feeds the IntPtrs? to the proper constructors based on the array of Types and then invokes the plugin provided Delegate.
• Possibly utilize an object cache in the api, and to manage the mappings between .net objects and their c struct counterparts so we're not constantly (re)building objects.
• ​grim provided gameplan

Mentor Goals/Objectives? (​grim)

• Implement signal chaining in Mono so Pidgin's signal handling doesn't get eaten up by the Mono runtime. See ​Mono Bug 75990.
• Fix the build system so that make can be run successfully with multiple jobs.

Loader Internals

The api objects now directly tap into libpurple using DllImport. This is true for purple_signal_connect also, which gives us a cleaner way to tie up signals in .Net. Going to need to explore an Object Manager so that plugins don't have to worry about IntPtrs and what not.