I've been playing around with vala, libpeas, and plugins loaded on the fly through libseed (javascript) and python.                                                                               
The way you make plugins in libpeas  is through extensions.  These can be defined through an interface.  It looks something like this:                                                            
public interface MyActivatable : Object { 
public abstract ScriptableWindow window { get; set; } 
public abstract void activate (); 
public abstract void deactivate();} 

Since libpeas doesn't really handle Vala code, I've been trying to write vala that compiles close to the same C code that libpease wants. 

The above interface works to some extent, but I did noticed that the  GIR file that  vala produces is not the same as what libpeas has.  They have a default interface called "Activatable"  whos GIR file looks like so (section):

<fieldname="activate">
<callback name="activate">
<return-value transfer-ownership="none">
<type name="none" c:type="void"/>
</return-value>
<parameters>
<parameter name="activatable" transfer-ownership="none">
<type name="Activatable" c:type="PeasActivatable*"/>
</parameter>
</parameters>
</callback></field>                                                                        

The GIr that vala produces looks like this however:

<callback name="my_activatable_activate" c:type="my_activatable_activate">
<return-value transfer-ownership="none">
<type name="none"/>
</return-value>
</callback>

It is missing the <field> tags altogether.  Since they are using some sort of automatic means of generating the GIR file, I wonder where these <field> statems come from.  I was told on the #libpeas IRC that the GIR creation is off in vala. 

There is something wrong in the GIR that causes all python plugins to crash when they use MyActivatable instead of the default Activatable from libpeas.