[KevinH]

I mean just that. Launching a plugin creates/forks a process and opens a pipe to it to wait and retrieve an xml file describing the changes the plugin wants to have made along with a folder with new or changed files in it. If you shudown Sigil, or cancel the running process this pipe is broken, so no changes inside Sigil are made. You are not given an option to attach or reattach to an already running plugin process.

So given the above, you really need to explain why creating a cache matters. And fwiw parsing a file or files is quite fast because the plugin has access to a fast C language gumbo variant parser. That gumbo parser instance is fully thread safe and can easily be parallelized for even more speed.

So what takes so much time that a cache is needed to keep state between invocations which would use different process ids for each invocation of a plugin anyway. And how would this help the majority of Sigil users?

You could always run a sha sum in your plugin on the epubs files and derive a launch time from the process id creation time inside your plugin and so create your own session key that would work for a sustainable cache that would detect if any incompatible changes have been made under Sigil (no matter when launched) and that requires no changes to Sigil at all.

What am I missing that would make this a useful change that can not already be done now?