RPC plugin API for enabling out-of-process (OOP) plugins - Version 2 #477

Open
Arnavion opened this Issue Mar 29, 2013 · 0 comments

Projects

None yet

1 participant

Owner

A new version of #452. Please read that first.

In #452 I had the following architecture

[             ]o <----------      ----------> o[ python-rpc.exe (script1.py) (script2.py) ]
| hexchat.exe |o <---------- DBUS ----------> o[ perl-rpc.exe (script1.pl) (script2.pl) ]
[             ]o <----------      ----------> o[ third-party-application.exe ]

I had mentioned that having the -rpc.exe's to act as script hosts would not eliminate the problem of CRT hell entirely, but merely move it from the main hexchat.exe to the individual -rpc.exe

I realized there is a much easier way to solve this problem. Instead of making the two -rpc.exe script hosts, we can have two scripts: python-rpc.py and perl-rpc.pl

Previously, I had wanted to convert the current python plugin.c to a stand-alone python-rpc.exe, which would expose the Hexchat Python API to the scripts it would host, and implement that API by talking to hexchat.exe over DBus. Now, I suggest python-rpc.py do this instead. When hexchat.exe starts, the following happens:-

  1. hexchat.exe enumerates all the python scripts in config\addons
  2. For each such filename $script, it invokes the user's installed Python as "%PYTHONDIR%\python.exe python-rpc.py $script". Each of these python.exe's is thus a sub-process of hexchat.exe ($script is an argument that will be parsed by python-rpc.py; see next steps)
  3. The newly spawned python.exe will execute the script it's been told to execute: python-rpc.py
  4. python-rpc.py initializes dbus, etc. It then loads $script and lets its init, etc. methods run.

To reiterate, python-rpc.py exposes the Hexchat Python plugin API (eg. Xchat.prnt). When the script calls Xchat.prnt, function Xchat.prnt defined in python-rpc.py will execute. The code in this function will then use the Python dbus library to connect to the Hexchat DBus endpoint for hexchat_print.

The same thing as above can be done for Perl.

The net result is:-

  1. python plugin.c -> python-rpc.py
  2. perl plugin-c -> perl-rpc.pl

Advantages

  1. No CRT hell in hexchat.exe
  2. No need to build perl or python as part of the build process.
  3. Potentially easier to maintain since all the Perl / Python interop code can be nuked.
  4. Scripts won't know the difference and will continue to work unchanged.

Disadvantages

  1. Requires the user to have the dbus plugins for Perl / Python installed. Stock installs won't be sufficient. We would need to detect this and warn the user.
  2. A few minutes of Googling reveals that there are in fact no dbus plugins for Python or Perl for Windows. Go figure. I suppose we can have a separate RPC mechanism for Windows (native winapi) and use Dbus only for non-Windows. Major pain point...

Therefore, the final architecture will be like this

[             ]o <----------      ----------> o[ python.exe (python-rpc.py) (script1.py) ]
[             ]o <----------      ----------> o[ python.exe (python-rpc.py) (script2.py) ]
| hexchat.exe |o <---------- DBUS ----------> o[ perl.exe (perl-rpc.pl) (script1.pl) ]
[             ]o <----------      ----------> o[ perl.exe (perl-rpc.pl) (script2.pl) ]
[             ]o <----------      ----------> o[ third-party-application.exe ]
@Arnavion Arnavion was assigned Mar 29, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment