> 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...

> It kind of seems to me like it has been a mistake to have both of these as completely separate things - something like a <canvas> that had a standard scene graph/metafile type library with it (that you could optionally use or not) that included hit testing would make more sense. That seems to be how things are going anyway with various libraries building on <canvas>.

Well, the Web has been built on mistakes and false starts. In this case the overlap between SVG and <canvas> seems mostly harmless (except for the browser bloat). But Javascript JIT's/graphics libraries combined with hardware accelerated <canvas> sure seems to be the likely winner at this point...

Hi Dave,

> In this case the overlap between SVG and <canvas> seems
> mostly harmless (except for the browser bloat).

Well, the other harm would come just from considerable browser development time sunk into some area that may not pan out.

The level of complexity involved with the whole SVG object model seems to be pretty extensive, for example there are 491 files in WebKit's \svg folder... That's a huge amount of effort in development, testing, bug fixing, ...

Certainly it's true that it is hard to know in advance which particular technology is going to become highly used or not... But on the other hand having too many huge mechanisms implemented and needed to be maintained can make it harder for browsers to be nimble as well.

- Michael