> Well yeah that, plus also distributing the additional DLLs that depend on such features, that's the part that really starts to bloat up the installer size.

Of course. Just thinking aloud about a future scenario where I dream up a really cool idea for a MoI plugin, but it needs WebKit component "X".

Perhaps once you're ready to start doing some customer alpha/beta testing you could provide a separate "developers only" download containing a set of drop-in replacement DLL's containing the full WebKit component suite for the more adventurous souls to work with. If nothing interesting seems to come out of it during the test phase, then they never make it into the final release build. Sounds like it might not be too much work on your part to set up. Just a thought...


> But also at some point I do want to have things set up so that MoI plug-ins could include C++ DLL code of their own mixed together with script.

Yeah! +1 for that.

> Just in general there isn't as much of a concept that MoI scripts have to be in some high security sandboxed environment as in a regular web browser environment. So there are already a lot of stuff that you can do in a MoI script like access the Windows FileSystemObject scripting API which is not allowed to be accessed from a regular web browser for example.

I just saw a codeplex project yesterday (Javascript .NET) that integrates .NET with the V8 engine. Something similar for Nitro could really open up the scripting API for MoI. Might be something I'll look into later...