I already have created a simple plug-in for my cosimulation plug-in for ProM. See my video demo here for more information about the current status.
The current plug-in handles “most” plug-ins, but it has at least four short-comings that would be neat to expand on.
First, it would be nice to be able to set simple properties directly. That is, currently all values are converted from a representation in CPN Tools to a provided object in ProM using a mapping. It would be nice to be able to instead use at least simple values like string and integers without this translation. It could also be very useful to be able to specify configuration objects for some plug-ins using a record. For example, one could assume that configuration objet adhere to the JavaBean convention. This would make it possible to easily specify configuration options and bypass the user-interface for configuration in many cases.
Second, it would be useful to provide a library of “standard conversions”. For example, a java.io.File object is in many ways the same as a java.lang.String, as we can convert back and forth with no loss of information. These could either be added explicitly or a generic conversion facility could be created (by inspection using reflection).
Third, it would be very useful to be able import and export values when a plug-in exists. This could be done by allowing import/export plug-ins to be used as well. Most likely, implementing the first two would make this near-trivial. It would be useful also to be able to export the view of an object.
Fourth, it would be useful to have a bit more control over the mapping. It could show a table like this:
The first column is a list of all transitions of the model. The second column lists all “matching” plug-ins. It is possible to statically infer (some) type information for each transition about pre- and post-conditions and only show matching plug-ins for each transitions. Adding conversion rules naturally complicates this, and choosing plug-ins defining post-coditions of some transitions would invalidate some plug-ins for other transitions. Plug-ins could be shown using 3 categories: matching, matching pre-conditions, and matching post-conditions. The “best” (based on names, e.g.) should be selected from the matching category. When another (especially when selecting one not from the matching category), the appropriate plug-ins should be automatically updated to predecessor/successor plug-ins (unless they have been manually set by the user). Most of the time, it should not be necessary to modify this mapping as reasonable and matching plug-ins can be selected automatically.
