[Bf-committers] VSE Strip-Wise Rendering

[Peter Schlaile]

Hi Dan,

> It has {application,plugin,libplugin} version control and symbol
> dependencies (as I understand them)

after reading again through the documentation, I don't think so. There is 
no thought put into negotation between the application and the plugin, 
what API version should be used for a specific interface.

The XML files are mandatory for libplugin, since otherwise, how should 
the system know, how the join-points are named, if a certain symbol is 
actually ment as a join-point? (I haven't actually found out, how 
libplugin checks, if the parameter declaration still match.
At first sight, it looks like it's left for the reader as an exercise...)
You can't just tell by using dlsym(), since in C, parameters aren't 
encoded into the symbol and C++ ABI name mangling changes between 
versions of C++-compilers, so I don't suggest using that instead...

And that is already the main problem: API versioning is done by just 
filling in the join-points that match (meaning: happen to have the right 
name...) and leaving those alone, that don't.

That means for the plugin author: check every function, you want to use 
from the core, a NULL pointer can sit *anywhere* around.

In fact, for any real-world-use in *Blender*, I don't think, that this 
whole XML-plugin-abstraction layer brings any benefit over just using dlopen(), 
dlsym().

It's even worse: it puts the interface declaration into external XML 
files, so you have to keep header files and external XML files in sync 
(without any help for versioning!) and: if something starts crashing, I 
wish you good luck by finding out, where, when, or what libplugin thought, 
should be replaced.

Please take a look again at my plugin system proposal, that actually tries 
to reduce symbol dependencies between core and plugins and also does API 
versioning in a proper way, that doesn't force the plugin author into 
checking every function pointer. I tried very hard, to make writing a 
plugin very seemless, though, every API is explicitly imported with a 
certain version.

And: I'm *really* a fan of well thought out external plugin APIs, that 
aren't changed as quickly as we release daily SVN snapshots.

I think, it is also every important, that *if* we change APIs, there 
should be a backward compatible way in requesting the old version of an API.
(It's not just: let's compare versions, GNAA, doesn't match. It's really 
about version negotiation!).

And: the API should be placed in C header files, so that the compiler can 
check for us, if something has gone awry. External XML files used for 
function declarations are really pretty much a disaster plan.

> You say 'centered on Linux' like that's a bad thing...

My personal opinion as a Debian-only user doesn't matter here. Point is: 
Blender is multiplatform, so the plugin system should better be, too...

Don't want to discourage your effort, but I still don't think, that 
libplugin is really part of the solution.

Cheers,
Peter

----
Peter Schlaile