Thread: ePUB Optimizer
View Single Post
Old 12-01-2014, 12:25 PM   #16
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 8,873
Karma: 6120478
Join Date: Nov 2009
Device: many
Hi Toxaris,

Quote:
Originally Posted by Toxaris View Post
I would really like a .Net plugin interface, but I assume that would be quite some work to do.
That really depends on how much hand holding you want to do for the .net plugin developer.

At its minimum, a plugin interface gets sent the the plugin type, the path to the plugin, the internal Sigil directory where the ebook files are stores (unzipped), and a temp directory that is created and owned by Sigil.

"Something" then has to protect the internal Sigil files, and allow direct reading of internal Sigil ebook files but that does a file-copy-on-write/change to the temp directory, keeping track of what has been changed by the plugin (modified, deleted, added). And then build a result xml stream that is returned back to Sigil with the list of changed, modified, added, deleted files.

Sigil takes this result xml stream and parses it and updates its own internal Sigil ebook files based on the result xml file and the modified files in the temp directory.

For python plugins, I wanted this to be as simple as possible, so I wrote a wrapper.py and *container.py classes that implement this "Something" for every python plugin. The wrapper.py will automatically parses the opf, and keeps track of copying the files upon write/change, which files you want to delete, which files you want to add, and it automatically creates the result xml file for the plugin developer. So the python launcher.py and wrapper.py code do a lot of hand holding and interface building for the python plugin developer so that they don't have to worry about the interface and result xml and copy-on-modify/write approach used to protect the ebook files in Sigil.

So if you wanted you could create a quite bare bones .NET launcher without the equivalent of the wrapper.py and *container.py and simply allow the plugin developer to have direct access to files and just tell them they need to write any changes to the temp directory, and make tell them to create their own result.xml instead of automating that, etc.

Then if interest develops, you could add some of the more powerful .net xml processing tools and develop a full-blown launcher/wrapper for .net

Take care,

KevinH
KevinH is offline   Reply With Quote