[Vote] Plugins about ntrremotedebugger HOT 8 OPEN

I'm all for plugins, but we'll have to hash out a solid strategy for interfacing with them, loading them, error handling passing between the classes that handle the network calls, etc. Also keep in mind that I'd like to support Mono if possible.

from ntrremotedebugger.

Well would love to have worked on this part-project. But as I can see now after good 8 months it's not a wanted feature by users. So I guess we can close down this issue/vote.

from ntrremotedebugger.

@f-israel people, like me, just never read their watch notifications, this would actually be an extremely useful feature, saves using a 3rd party tool to convert between formats, as i have in the past

from ntrremotedebugger.

@ObscenityIB I thought this one was dead already. Nice to see that I was wrong. Guess it's time to reopen this issue. Maybe this time will be more user resonances.

Originally I thought more of game specific UI plugins. But the idea of "extending" the base features this way sounds also appealing and - no matter how much I think about - isn't that different.

As @valarnin already said we need to work out an solid interface. Something network independent as a (simple?) format converter shouldn't need that much but could be a good starting point.

I didn't look into the source since my last merge request so I can't tell right now if it's easy or extrem to implement. But disregarding that one: I'd love to see some more concrete information of your idea/feature.

from ntrremotedebugger.

Some quick thoughts on Plugin implementation, written in haste:

Load methodology:

1. Check for Plugins directory

• In CWD, or in AppData folder?
• If in AppData folder, autocreate, if in CWD, don't

2. List files in Plugins directory that end in .cs
3. For any plugins that end in .cs, compile them automatically

• Link against main executable
• Plugins should store the version of main executable they're compiled against so that breaking changes don't try to autoload plugins that are no longer compatable
• If existing DLL for cs and version is out of date, recompile it

4. List files in Plugins directory that end in .dll
5. If file count is greater than 0, add a Plugins GUI item somewhere (TBD, maybe a button, maybe a dropdown menu)
6. Load each Plugin DLL, allow them to register items into Plugins GUI by invoking a register method

• Register method should return object of type PluginGUIItem, which has fields:
• • Name - String
• • Callback - Callable, nullable, optional. Used to run functions or to display GUIs, etc
• • List of PluginGUIItem objects, to allow for nesting items

Things that will need to be done to support plugins in general:

1. Event Bus will need to be created, and any network events / timer events will need to emit an event onto the bus.

• Plugins can register event handlers to bus, as well as invoke events on the bus

2. Network code will need to be exposed via APIs so that plugins can invoke them
3. PluginGUIItem class needs to be created and exposed on executable for compiling against
4. Some code may need to be refactored to move off the GUI thread and to a worker thread if plugins can invoke that code

from ntrremotedebugger.

Sounds robust.
What do you mean with "event bus" exactly? Just some invoked events or a full message queue?

I guess I'll play a bit with dynamic compiling. If enough time I'll create a (dirty) prototype.

from ntrremotedebugger.

No need for a full MSQ, that's overkill. Just simple event emitters/invocation. I just used the term Bus as a general catch-all to indicate that the event management should be centralized.

from ntrremotedebugger.

@valarnin could you try to compile and run the attached code please? This should be a possible base for dynamic code compiling. I'd never done this before so it's just a hack-together and far from the best and safest. Please check if compatible with Mono.

If success the console output should just be a two-liner:
FirstNamespace.testclass1
secondNamespace.testclass6

DynamicCompiler.zip

from ntrremotedebugger.