planning
<h2 class="Heading">About this document</h2> This document is intended to enumerate the possibilities for the future of CellML tools. As such, if you feel that you have anything to add, please make the changes(or if you have insufficient access to the site to do this, e-mail your suggestions to ak.miller@auckland.ac.nz). <h2 class="Heading">Intro</h2> <p>We are now at a point where we have to consider how best to continue our tool development projects. There are several reasons it is timely to consider this now.</p> <ul>
<li>We now have a new CellML API implementation. None of our existing software uses it (cmiss, mozCellML, cell editor).</li> <li>We want a more seamless work environment for authoring models and running simulations</li> <li>There
are mixed views on the appropriateness of various design choices and technical implementations of what we currently have (cmgui, svg, canvas, xul, java, corba,...). The debate needs resolution so we can move forward more effectively. We want a framework that can incorporate other projects, such as Sarala's work.<br></li> </ul> <br> <h2 class="Heading">Objectives</h2> <ul>
<li>Easy to use environment for authoring models, running simulations, publishing and reviewing models.</li> <li>Target users?</li> <li>Target platforms?<br></li>
</ul> <h2 class="Heading">Similar Software</h2> There are currently several pieces of widely used software that provide similar functionality to what we are try to achieve with these CellML tools. They are typically focussed within a specific domain, with some exceptions. While none of them are open source, they all have significant numbers of users and we should be drawing from their experience in developing usable tools.<br> <ul>
<li><a target="_self" href="http://nsr.bioeng.washington.edu/PLN/Software/">JSim</a></li> <li><a target="_self" href="http://www.vcell.org">Virtual Cell</a></li> <li><a target="_self" href="http://cor.physiol.ox.ac.uk/">COR</a><br></li> <li><a target="_self" href="http://ssd1.bme.memphis.edu/icell/">iCell</a></li> <li>others?<br></li>
</ul> <br> <h2 class="Heading">Current Status</h2> Summary of our current tools.<br> <p><b><br></b></p> <p><b>mozCellML:</b> Simulation environment written in XUL, Javascript, C++. Uses Cmgui for graphing via CORBA</p> <p>pros<br></p> <ul>
<li>mozilla toolkit, which is widely considered the best XML
workbench, support for MathML, SVG, XHTML etc. Good for building network aware application, for model repository interaction. Separation of GUI and backends. NOte this has nothing to do with a web browser.<br></li>
<li>good pathway for cross platform distribution and automatic updates.<br></li>
</ul> cons<br> <ul>
<li>current virtual desktop design has problems</li> <li>gui not at all friendly to the casual or firstime user.<br></li> <li>cmgui not yet fully functional as a plotting tool</li> <li>simulation
speed questionable(note: this is not due to the graphical environment but a consequence of the algorithms used in the back end).</li>
<li>compatibliity
with non-mozilla based web browsers (IE, opera). (CS. Need to support xulrunner to remove browser dependence - not a big deal. Toolkit choice has nothing to do with web browsers)<br></li> </ul> <br><b>Cell Elite:</b> CellML authoring environment written in Java<br>Around 80% of the code deals with user interface API like java.awt.* and javax.swing.*.<br>pros<br> <ul>
<li>"Write once, run anywhere" that that has a Java interpreter(i.e. better portability of binaries, in theory).<br></li>
</ul> cons<br> <ul>
<li>Integration of the CellML editor and MathML editor are
currently very poor: it is serialised to XML, saved to disk, and then the MathML editor is invoked on that file. It is then re-serialised and passed back via the disk to the CellML editor. This seems potentially quite disruptive to users' normal workflow, as the CellML document isn't available while the user is editing the MathML.</li>
<li>A
canvas is used to paint the boxes used for the graphical display, rather than a vector graphics approach like SVG. As such, some degree of flexibility, which would permit extensions like Sarala's work, is lost.</li>
<li>Currently there is no separation of concerns between the GUI and the code, as all packages reference the Java GUI APIs.<br></li>
</ul> <br> <h2 class="Heading">Pathways Forward</h2> <br> <h3>Migrating to the new CellML API<br> </h3> The CellML tools do not currently use the new CellML API, but it would be useful if they did, as we currently have a large number of incompatible CellML APIs.<br><br>mozCellML currently has its own CellML API, which is tightly coupled with the function of mozCellML. The C++ part of mozCellML will require a significant rewrite to make it work with the new API. However, changes to the Javascript/user interface code should not be necessary.<br><br>For API, the current editor has about 3000 references to its Java CellML API, spread throughout the codebase. Around 30-50% of the code needs to be reviewed to fully understand/be able to modify the API usage.<br><br> <h3>Other possible changes</h3> The issue of integrating the tools actually has two almost orthogonal aspects to it:<br> <ol>
<li>Making the tools refer to the same data. This means that
changes in one tool will take effect in the other tool, but doesn't mean that there will necessarily be any closer integration than that.<br></li>
<li>Making
the tools appear in a consistent environment, for example, providing a single window in which both tools can be used, and as such, facilitating workflows that involve both tools.</li> </ol> <br>We have a number of options with regard to implementing one or more of these:<br><b>1. Data sharing only:</b> Continue development in the current frameworks.<br> <div>Migrate both mozCellML and Cell Elite to use the new CellML API. We can then use the "CellML Events" specification, which is currently being developed, to communicate between the applications. Communication could be across CORBA, or we could develop code which automatically maps our IDLs to JNI(Java Native Interface) and XPCOM(Mozilla's component object model).<br></div> <br> <div>This has the benefit of requiring less changes to achieve it, although migration to the CellML API will still be a large undertaking.</div> <br><b>2. Adopt Framework eg Eclipse:</b> Migrate to an established framework.<br> <div>Eclipse is a well established environment for building Java based tools. It offers the similar services to a window manager, and in addition, offers some services specific to editing files, such as notification of when the file has changed(although these seem mainly intended for plugins which re-parse the entire file when any part of it changes, and so may not be well suited to CellML tools).<br></div> <br><b>3. Migrate towards the Mozilla/XULRunner platform<br><br></b> <div><i>For most people Mozilla means web browser. However for developers the Mozilla platform is actually a toolkit, like Java, QT or GTK. Firefox is a web browser built using the Mozilla toolkit. We are using the xulrunner target in this discusison to emphasise that this development has no dependance upon a web browser. The use of the name Mozilla is used to refer to the toolkit, not a web browser.</i><br> <br>Designate the Xulrunner platform as the core technology of choice. Along with this we need to decide what supporting tech will we use or develop.<br><br>The Mozilla platform already offers a lot of technology which can replace work done on the editor out-of-the-box. For example, it has native SVG support with a fairly complete implementation(note that Batik, a Java product, is also available). We can write a lot of the code in platform-neutral Javascript, while still easily connecting over XPCOM to native code(which can be largely source-portable due to the libraries provided by Mozilla).<br><br><br></div> <div>How do we get there? <br></div> <div>Embed the existing java tools directly(perhaps as an applet)? This would be faster to implement, but it would give quite poor integration.<br><br></div> <div>Rewrite existing Java tools for the Mozilla platform? By migrating to the CellML API it is likely that a high level of rewriting is required anyway, so it is not clear that this is better or worse than any other option.<br></div> <i><br>matt We need to consider those that want to write their functional parts in languages other than C++ or Javascript. For Java there is <a href="http://developer.mozilla.org/en/docs/JavaXPCOM">JavaXPCOM</a>, for python there is <a href="http://kb.mozillazine.org/PyXPCOM">PyXPCOM.</a> It is important that Sarala can continue to develop her functional code in Java.</i><br><br><br> <h2 class="Heading">Exploring the Pathways: 2. Adopt a Framework<br></h2> <br>This would require either a port of mozCellML to Java(which would likely be costly in terms of both developer time and performance, especially if the integrator is to be run in Java as well), or to use Rhino(a Java based Javascript engine) instead of the faster Spidermonkey engine used by Mozilla for the user interface, and Blackwood for Java-to-XPCOM access. This would likely have performance consequences, although the integrator could be kept in C.<br><br> <h2 class="Heading">Exploring the Pathways: 3. Migrating to Mozilla/XULRunner Platform</h2> The mozilla platform is attractive because:<br> <ul>
<li>Good cross platform toolkit<br></li> <li>Widely considered the best XML workbench, support for presentation MathML, SVG, XHTML etc. <br></li> <li>Good for building network aware application, for model repository interaction. <br></li> <li>Separation
of GUI and backends. Javascript for GUI (python support not far away), C++, python or anything wrapped in XPCOM for backend components.<br></li>
<li>good pathway for cross platform distribution and automatic updates.</li>
</ul> <br>mozCellML already Mozilla platform based, only need to connect Java based tools. The Java tools could be either embedded largely as are within XUL interfaces, like applets, or rewritten.<br><br>A significant rewrite of the Java tools is needed to move to the CellML API. This will need most code to be checked and differences from the current API to be identified and fixed(around 20,000 lines could potentially contain calls to the CellML API, but we should be able to identify which ones are a problem just by attempting to compile).<br><br>Graphics in the CellML editor use a canvas to paint the controls, rather than using SVG. This could potentially cause problems for work extending the editor, and so a move to SVG would be very beneficial. This would probably require most of the cml.draw.* package to be replaced(1817 lines to be deleted, but we could probably replace it with less code using SVG), and possibly other changes throughout the codebase too.<br><br>Useful resources in the current Java tools:<br> <ul>
<li>Imported object promotion: the Java code provides tools
for splitting initial conditions and MathML into separate documents, and we do not have support for this anywhere else.<br></li>
<li>The
Java API contains code for a property representation of CellML models, i.e. plain English strings which describe a model in terms of properties. These strings could be useful to us.</li> </ul> Strategies to leverage the existing Java code:<br> <ul>
<li>Refer to them when porting to another language.</li> <li>Access them, perhaps across CORBA, JNI, or Blackwood(this could be more trouble than its worth).</li> <li>Automatically
extract strings from them, either by an external parser, or from Java, using reflect, and converting these into a useful format(its not clear how easy this will be, but it might be possible for the properties, and so could give a port a head-start).</li> </ul> <br> <h2>Development times and costs</h2> <br> Need more documentation on the pathways, including time estimates. Also need discussion on issues such as <ul>
<li>resourcing, do we even have the time to consider this undertaking is it really worth it?<br></li> <li>available
expertise, can always get java developers, however mozilla platform requires a higher level of expertise to develop beyond the XUL GUI's. Only people with experience are Andrew, Matt, Carey and Shane - Matt is part time, Carey leaving, Shane very busy</li> </ul> <br>Currently the CellML Editor uses about 45,000 lines of code, although this would likely be less if it was written in a language like Javascript.<br> <h2 class="Heading">mozCellML Issues to Resolve</h2> Issue 1: Layout<br>Continue with virtual desktop approach(note these also apply to using javax.swing.* and so also apply to using Java for Cell Elite):<br> <div>Advantages:<br> <ul>
<li>Nicer user interfaces, as there is no other portable way
to provide the user interfaces and workflows that were created as a result of user feedback.</li>
<li>Consistency cross-platform, and ease of porting.</li>
</ul> Disadvantages:<br> <ul>
<li>Doesn't interact well with plugins or cross-platform embedded windows.</li> <li>Doesn't
preserve a user's window manager settings for window look-and-feel(Mozilla gets around this to some extent by writing different XULs for different platforms).</li>
<li>Javascript code
can't see mouse events after the mouse leaves the document, and so it can't distinguish a mouse down, mouse exit, mouse up, mouse enter from a mouse down, mouse exit, mouse enter. This means that dragging virtual window boundaries to the edge of the parent window can be confusing. However, the current behaviour could still probably be improved, making this a minor issue.</li>
<li>non-standard user interface resulting in user confusion and extra code to be maintained.<br></li>
</ul> </div> <br>Issue 2: Graphing<br><br>Continue with cmgui for plotting?<br> <div>Advantages:<br> <ul>
<li>Could be leveraged by cmgui users(?)</li> <li>Provides a use-case for cmgui, and so drives improvements to cmgui.<br></li> <li>Political implications of using our own product over external options.</li>
</ul> Disadvantages:<br> <ul>
<li>A heavy-weight solution to a simple problem(binary size, memory usage, startup time, etc... less than optimal).</li> <li>Portability
issues with embedding windows cross-process — especially painful to get right on Win32, due to race conditions between Win32 messages and communication with cmgui. Win32 also doesn't get the repaint order right in all circumstances. Clearly this is not often used on Windows, and so not extensively tested by Microsoft.<br></li>
<li>Difficult
to build outside of the institute, especially on Win32 — since the addition of cmgui, the advice to users has been "don't try to build this unless you have to" rather than the tradition for open source software of encouraging source builds.</li>
<li>Currently makes heavy use of Perl, although this may change with cmgui updates.</li> <li>Embedding
windows cross-process makes proper integration tricky — incompatible with virtual windows(or SWING if we port to Java), as one system window is either completely behind another or completely in front.This makes it impossible to implement some user interface features correctly.<br> </li> </ul> </div> <br>Use Canvas element?<br> <div>Advantages:<br> <ul>
<li>Lightweight(comes with Mozilla platform already, very fast to set-up, and only stores a single bitmap of the graph).</li> <li>Possibility
of using existing graphing library(although it is not clear they will be useful to us without extensive modifications => it might be easier and cleaner to write our own).</li>
<li>Easy to
maintain(only a few screens of Javascript code were needed to implement axis labelling), C++ code to plot data should be simpler than the current code to send data and keep the scales up to date.</li>
<li>Will interact properly with both virtual windows and system windows.</li>
</ul> </div> <div>Disadvantages:<br> <ul>
<li>Non-heterogeneity with SVG based tools. This is only
really an issue if we want to plot graphs amongst the shapes in Cell Elite. Also non heterogeneity with others in the institute using cmgui.<br></li>
<li>Text
is a pain, as it cannot be drawn on the Canvas. Instead need to use CSS position: absolute and move text over the graph. However, this only required a page or so of code to get right in my mock-up scale-free graph axis page.</li>
<li>Need to repaint all the data every time we change the scale due to new data or user activities like zooming.</li>
</ul> </div> <ul> </ul>
<div> </div> <br>Use SVG ?<br> <div>Advantages:<br> <ul>
<li>Lightweight for graphs with small numbers of points.</li> <li>Can
re-use SVG in a number of contexts, e.g. to draw graphs(possibly with transformations applied) in the editor, or served up via the CellML repository.</li>
<li>Can simply apply different transformations to existing graphs to change scale etc...</li> <li>More widely accepted standard.</li></ul> Disadvantages:<br> <ul>
<li>Memory
and time utilisation increases faster than the other approaches with number of points, and so graphs with large numbers of points(probably 1000s to 100,000s, depending on memory, CPU, etc... available) are likely to result in memory exhaustion or very poor performance. This is due to the fact that DOM/XML technologies are generally inefficient for representing large amounts of data. Mozilla SVG has known efficiency problems for large documents.</li>
<li>Although we don't have
to explicitly redraw, the SVG engine still has to when we change the scale, so we are not necessarily gaining any performance, just shifting who does the work.</li>
</ul> </div> <br>Use OpenGL directly?<br> <div>Advantages:<br> <ul>
<li>Can create draw lists for the data, and so get better graphics acceleration.</li> <li>Much more lightweight than a complete cmgui process.</li></ul> Disadvantages:<br> <ul>
<li>Still need a plugin, which brings all the problems of having a system window.</li> <li>Not
clear how much work needs to be done on the XPCOM-OpenGL code to make it work on all platforms, and bring it up to date with changes made since it was created.<br></li>
</ul> </div> Issue 3: Access to the CellML API<br>Use CORBA<br> <div> <ul>
<li>This
provides an obvious strategy for integrating CellML tools: they simply connect to the local model server via CORBA, get a list of open models, and then modify them. Other applications can monitor for changes.<br></li>
</ul> Advantages<br> <ul>
<li>Easily
extensible, as any number of new tools could interact using the standardised CellML API and the upcoming CellML Events API, from a diverse range of different languages.<br></li>
<li>Very little effort required to create distributed CellML processing systems on top of this.</li> <li>The standards compliant approach.</li> <li>CellML
tools can easily be run separately, and will be isolated from each other by process boundaries(giving additional robustness).</li>
<li>XPCORBA already written, so will let the distributed refcounting work properly from Javascript.</li></ul> Disadvantages<br> <ul>
<li>CORBA requires a number of libraries to use.</li> <li>CORBA
imposes a performance penalty, as it must marshall, send across some form of socket, and unmarshall the request. Whether this is significant is unclear.</li>
<li>On Java, also need to generate finalisation code to make distributed refcounting work.</li></ul> </div> <br>Use of a custom mapping from XPCOM(or any other languages we use) to the CellML API<br> <div> <ul>
<li>Also useful for CMISS, if we support 32 bit and 64 bit Linux, AIX and (being deprecated) IRIX, and define bindings for F77 or other languages CMISS may use.</li><li>We
write code to translate the API IDLs into code to connect the CellML API to XPCOM and/or JNI, and any other languages we need to access it from.</li>
<li>omniidl, part of omniORB, already provides an
extensible framework for writing IDL compilers in Python. All the IDL parsing work is already done, so only need to write the code generation code. We have already used this to generate the C++ header files for the CellML API.</li>
</ul> Advantages:<br> <ul>
<li>XPCOM access faster. JNI probably faster, although JNI is known to be slow as well. Speed is also very important to CMISS development.</li><li>Reduced compile time dependencies on other packages.</li></ul> Disadvantages:<br> <ul>
<li>No cross-process boundary, which has implications for robustness against programmer error.</li> <li>Need to write a new binding for every new language we want to work with(unless we can go via XPCOM).</li> <li>Cannot
easily be distributed(although this option does not preclude building a CORBA server into the Mozilla process at a later time).</li><li>Maintaining multiple language interfaces.</li>
</ul><hr size="2" width="100%"><br>Matt's vote:<br><br>Mozilla/XULRunner platform - the most obvious reasons being those stated in the document:<br>----<br>The mozilla platform is attractive because:<br><br> * Good cross platform toolkit<br> * Widely considered the best XML workbench, support for presentation MathML, SVG, XHTML etc.<br> * Good for building network aware application, for model repository interaction.<br>
- Separation of GUI and backends. Javascript for GUI (python support
not far away), C++, python or anything wrapped in XPCOM for backend components.<br> * good pathway for cross platform distribution and automatic updates.<br>-----<br><br>We should use the C++ implementation of CellML API with CORBA interface for all components.<br><br>JavaXPCOM for those that want to write functionality in Java - this needs to be tested and demonstrated, it is imperative that Sarala can continue to develop her functional code in Java. Her User interface will be XUL and SVG. The best demonstration to make her happy would be an SVG document evoking java code through events.<br><br>For ontologies, the Jena framework seems the most useful production level OWL api and query interface. This adds to the importance of having JavaXPCOM working.<br><br>With respect to "Strategies to leverage the existing Java code" - I think just rip out the API and all GUI code and leave functionality in Java. But that's just a guess at the moment, I am no too sure how intimate the functional code for the CellML editor is with the GUI framework. I presume Dong would be doing this.<br><br>I think it is worth any developer becoming familiar with writing applications in the Mozilla framework. And I think it's worth not hiring anyone who couldn't cope with that.<br><hr size="2" width="100%"><b>Cellml model Developer Enviornment (Steve Niederer)</b><br> <br>
<p>Desirable features:<br> <br> All of the current cellml editors have numerous strong points. Some potential features that would be desirable to include in a new development and solving gui for a cellml developer environment would be:<br> <br> Developer<br> <br> 1) Equations should be input in text in a manner similar to Matlab, Fortran or C++<br> 2) A tree of components<br> 3) Components would ideally be collapsible<br> 4) An efficient search tool for finding variables, this would include the ability to high light all the times a variable is used in a file and a search function which provides a list of matching variables (for the times you cant remember the exact spelling) <br> 5) A box which shows you a 'pretty' form of your equation so that it can be easily compared with a journal article<br> 6) The ability to export the cellml files to matlab, c++, fortran, tex .....<br> 7) No cellml tags at all<br> 8) The ability to add meta data but the ability to hide it as well<br> 9) The ability to look at and edit the model connectivity in the box method used in the current cellml editor.<br> 10) A font set where semi colons and colons look different, where 1's and l's look different<br> 11) The ability to check the validity of the cellml /xml<br> 12) A debug function which high lights the line which is causing the problem and explains what the compiler was looking for and what it found.<br> 13) The ability to import equations written in different languages.<br> 14) A clear help file with worked examples<br> <br> Solver<br> 1) The ability to plot more than one trace on two different axis at the same time<br> 2) Axis with numbers on them<br> 3) the ability to easily select what trace is displayed, preferably from a tree which represents the model structure and states if the variable is a function, ode, or parameter. It would also be good to be able to sort the list of model variables by functions, odes and parameters for either the whole model or within components <br> 4) The ability to solve the model with different parameters and easily overlay the traces<br> 5) The ability to define a series of simulations you would like to run in a virtual experiment <br> 6) The ability to define certain characteristic measures of a trace (i.e. half time to relaxation , decay rates, slopes, action potential durations, etc) <br> 7) The ability to define pacing protocols<br> 8) The ability to define the x and y axis for a given plot<br> 9) Even to define the z axis if you are using cmgui<br> 10) The ability to export the trace to a cvs file where you don’t need to click save twice.<br> 11) The ability to run long experiments<br> 12) The ability to import experimental data points and overlay them on your simulation results<br> 13) The ability to define the names of the x and y axis, legends etc to produce publication quality figures<br> 14) clear indications of what has gone wrong when the solver fails to work, a means to export diagnostic information<br> 15) The ability to solve 1D or 2D propagation problems<br> 16) Ability to test constitutive laws<br> 17) the ability to preform a solve to zero time<br> </p>
<hr size="2" width="100%">
</div>