DISCLAIMER: This post will be long and boring and it will raise non-trivial Java topics (which I am not sure to understand 100% myself, being a C++ programmer, before than a Java programmer...). However, at least the first section Why? might be of general interest.
The two following example scenarios should show why Inter Plug-In Communication (IPIC) might be useful:
1) Assuming we already have an "Area Protection" plug-in with some basic features and a "Money" plug-in also with some basic features;
2) A new "Shop" plug-in is developed, implementing shops, for instance using chests or crates as item containers.
3) This "Shop" plug-in would find useful to query the "Area Protection" plug-in for chest accessibility (we do not want buyers to access any chest, only those in unprotected areas or in specially defined shop areas) and to query the "Money" plug-in to check if the buyer has enough money or to tell it to subtract the relevant amount in case of a buy.
This is to avoid to have (almost) anything in (almost) any plug-in. Once the first two plug-ins provide some basic features, other plug-in can add more features, piggybacking on them. Note that even including the "Shop" feature in the "Money" plug-in would not avoid the need to query the "Area Protection" plug-in for chest accessibility (or vice-versa if the shop feature is implemented in the "Area Protection" plug-in).
1) Assuming there is an "Objects" plug-in which places static objects (and we have one!!!); it may have interesting features like visibility management depending on player distance, or some simple animations (let's say rotating elements);
2) A new plug-in is developed which implements wind mill (to produce flour or olive oil or whatever) or water-driven power facilities (and electricity management).
3) The latter plug-in might find useful to ask the "Objects" plug-in to display its mills or power facilities rather than re-inventing the wheel from scratch; it may also take advantage of any improvement the other plug-in may gain over time.
In practice, IPIC would allow each plug-in to leverage whatever feature other plug-ins already have and decided to share, minimising development effort and maximising features and feature quality, as each plug-in could focus on its 'core business', making it as polished and as robust as possible, without being distracted by nice-to-have but collateral features, which could become the 'core business' of other plug-ins.
This is where things go muddy...
Before looking elsewhere or waiting for some API expansion, I looked at what the current plug-in API has to offer right now. And I found at least two areas:
*) Custom events (supported by the Plugin.triggerEvent() method). This might be useful for some kind of IPIC, but it seems to be intended for notifying of some context change whomever might be interested, more than to query a specific plug-in for a specific datum or action. It is also cumbersome to get one or more return values (query) from this methodology. There are work-around, involving synchronisation and custom objects defined by each plug-in to pass data back and forth, but they are cumbersome and not very robust.
*) Direct plug-in access (supported by the Plugin.getPluginByID/Name() methods). This allows to retrieve an instance of a specific plug-in and, potentially, to invoke any of its public methods: quite near to the mark!
Unfortunately, both methodologies suffer from a serious drawback: both require the target plug-in to be in the CLASSPATH. Apparently, no plug-in .jar is in the CLASSPATH (which makes sense from some point of view), so no plug-in can access the definition of other plug-in classes (or inner classes); trying results in a run-time java.lang.ClassNotFoundException.
There are ways to dynamically add plug-in .jar's to the CLASSPATH, which involve ugly tricks based on reflection. I tried on a local dedicated server and it works: I could call a public method of a plug-in from another plug-in.
In principle, it would be possible to encapsulate these tricks in a specific IPIC plug-in, exposing neater methods for other plug-ins to register themselves as sources and publish methods, making the life of plug-in developers easier. Still, there seems to be no way to ensure this plug-in would be loaded first to be immediately available to other plug-ins (registration of a source plug-in is likely to happen at plug-in onEnable() )
Then, there are the already invented wheels:
*) JMX and its various flavours of MBean's: it has the advantage to be already included in any JVM and to be relatively easy to use, once you know its concepts. I have not tried it yet in the RW context, but I assume it is going to work. Still, forcing plug-in developers to learn another (slightly esoteric) technology in order to create plug-ins is not going to help a wide adoption of the IPIC concept (rather useful, as we saw).
Again, it is possible to hide the technicalities in an IPIC specific plug-in, providing other plug-ins with 'simple' ways to publish access to data and methods (if they choose to), but still it would be necessary to ensure that this plug-in would be loaded before any other, and this do not seem possible at the moment.
*) OSGI is the obvious 'big guy' of the block. However, it might be over-kill and it is likely to require a built-in support form the RW framework itself. So, not for now, I'm afraid.
*) Java Module System also looks appropriate, but it was not here yet, last time I checked.
In summary, there are ways to implement IPIC right now. However, all of them have a more or less steep learning curve, require more or less esoteric code snippets to be added to the plug-in source and none is really 'plug and play'. Worth pursuing anyway?
If anyone has other suggestions, proposals, comments, I am eager to hear them!