RGI Registration Method — Alternate plug-in registration method using RGI files
The original and standard plug-in registration procedure consists of querying (i.e., running) each plug-in by plug-in proxy on Gwyddion start-up. The queried plug-in prints its registration information to standard output and plug-in proxy captures and parses it.
The standard method has two problems:
Thus an alternate plug-in registration method was implemented, using RGI (ReGistration Information) files.
When plug-in proxy finds an executable plug-in, let's call it
foo.exe
, before trying to run it it looks for
following files (in this order):
foo.exe.rgi |
foo.exe.RGI |
foo.rgi |
foo.RGI |
If the plug-in filename has no extension, only the first two are tried. If it has more extensions, only the last one is replaced.
The first file found (if any) is used instead of the standard output
of foo.exe
, i.e., as its registration data.
If none of them is present, the registration continues as usual by
running foo.exe
with a register
argument.
After a successfull registration, there's no difference in actual execution of plug-ins registered by running them or using a RGI file.
The easiest way to create a RGI file for an existing plug in is to make it dump the registration information to a file:
1 |
foo.exe register >foo.exe.rgi |
The main problem is that the contents of a RGI file must be kept up to date with corresponding plug-in, if its specification changes.
The RGI method also allows to register a plug-in that is not possible to actually execute on a given system, and thus confusing the user. For example, it's possible to register a Python plug-in where Python interpeter is not available, or executables for a different operating system.