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 _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers