On 14-05-16 06:43 PM, Matthew Brush wrote:
[snip]
As mentioned above, this doesn't seem worth the trouble and I don't think it would be as easy/useful as it seems on the surface. We could just leave the existing loader without breaking anything, it's quite stable and works pretty well for plain C plugins that don't want to use GObject-ish stuff. We could document the Peas loader and related work as provisional while we get it all integrated and working well with the GI bindings and still leaving the existing stable C loader in-tact during this time and for the foreseeable future.
Just to be clear, I don't mean to imply that we shouldn't make any effort towards providing a simple way to adapt existing plugins to use the new loader with minimal changes, just that I don't think that this mechanism or some compatibility layer for the loader needs to be a blocker/priority towards providing an alternative parallel loader that eases working in other languages and paves the way for more specific and powerful extension points with more idiomatic interfaces and APIs in multiple languages.
Cheers, Matthew Brush