Cool, at least what I understood of it was correct.
It isn't masses of code to duplicate in either case, but it would be silly of me to do so if my approach should be changed to get a more direct reuse without adding to the potential future maintenance burden.
I guess what I had in mind is that as a user I want the ability to stick my latest howdy doody cover I downloaded into Calibre on the front of my ePub.
As I understand it (which could be utterly wrong) at some point in the history of the book it needs to be converted using Calibre to get the special cover xhtml page as defined in the guide and identified with the metadata tags in that page. I "think" this is what you call the "raster cover"? From that point on, it is possible for that cover to be overwritten when using save to disk etc in the target copy of the ePub.
What that doesn't do is update the cover on the copy of the ePub in your library. For that you have to reconvert the book again (or presumably reimport it back from your save target). And you would also have to do a conversion for a first time book.
So given this plugin is considerably about "avoiding full-on conversion" I was thinking it would be a desirable feature to handle both updating metadata for a previously converted book, and inserting the html/SVG wrapper if it hasn't been converted previously. Either way it means the ePub in your library now will have the latest image to match what you see in the pane and on your device.
That was the theory. Of course that may be a pit of despair to attempt to implement of course.
I found/replicated the code to serialise through the metadata and cover to my worker processes, so the raw data is there. I'm guessing there are probably lots of nasty special cases that all those masses of code in Calibre over many years are taking into account that may make it not as "simple" as it sounds...