Discussion 2008 Hackathon
This is a summary of the discussion about libSBML modularization, with other comments that came up in conversation afterwards.
It was generally agreed that libSBML core would need to keep some sort of register detailing what extensions were available and that these need to called from libSBML core.
Stefan Hoops brought up the point that it is possible that some extensions may need to dealt with before others; i.e. that ordering of extensions may be necessary. He also pointed out that it may be the case that there are circular dependencies between extensions.
Darren Wilkinson raised the issue of actual conflict between extensions.
Whilst these are partly matters for SBML level 3 development, they are issues that will need to be handled by both libSBML core and any extensions. Thus it is probably sensible to anticipate the problems as far as possible and develop a strategy for dealing with them.
This didnt really come up in general discussion. However, Sven Sahle later suggested that it was perhaps unnecessary to dynamically load libraries. He argued that since most developers using libSBML would be aware of any extensions they wished to use, they could (and probably would) statically link to the required libraries.
Jim Schaff felt that since the extension libraries woud limit their functionality to the scope of libSBML functionality (i.e. read/write/validate), they would not be large enough to prohibit compile time building/linking.
Darren suggested that we avoid the need for either internal registry or loadlibrary by using an add-on system similar to that used by Firefox, i.e. a specified directory for add-ons with a registry maintained in that directory.
The proposed idea for read/write etc by passing control to other libraries seemed to be acceptable, with the proviso that we need to consider dependencies and ordering in relation to the extension libraries.
Stefan thought that it would not be necessary to pass control to other libraries during a write process. The existing xml layer should take care of any additional components/attributes.
Frank Bergmann asked whether information in an SBML file would be preserved, even if the extension required to parse it was not available. This does need to be considered. It also has implications for writing out such a model.
The need for multiple models within documents and the 'parentage' issue that can cause mistakes in using libSBML (see createSBML) was acknowledged but not really discussed further.