Meeting Minutes 30 March 2006
Present: Carey Stevens, David(Andre) Nickerson, Poul Nielsen, Dong Zhang, Steve McKeever (from Oxford), Shane Blackett, Peter Villiger, Sarala Dissanayake, Andrew Miller
Andre: Queried whether our "planning" document will be used by the CMISS group, and if so, whether they should be informed.
Carey: Noted that there was debate about who our tools are targeted at: people at the institute, or lay biologists.
Poul: Believes that some level of integration between tools is important in the long term.
Andre: Queried whether we should be developing our own in-house tools, or working with external software vendors to encourage them to support CellML.
Shane: Expressed concern about the idea of starting fresh on the CellML editor, given the past work put into it.
Dong: Noted that there were differences in the asthetic look between Java and Mozilla, and stated that he prefered the Java look.
Poul: Noted that he believes we should use the CellML API internally, as we want to demonstrate to others outside the institute that it is usable, and our use(or non-use) of it internally will affect the credibility of that claim.
Poul: Queried the meaning of Carey's comments in the "planning" document about browser independence(in response to Andre's comments).
Shane: Asked whether there will be any difficulty synchronising the Javascript user-interface and the C++ backend.
Poul: Asked why the document claims that the Javascript code for the editor would be shorter than the current Java code.
Shane: Suggested that we should have more information on the costs of development, with time estimates on how long the changes will take.
Poul: Queried what the "virtual deskop" was exactly.
Poul: Asked about how bad the SVG really is:
Poul: Asked about the OpenGL section of the document, and whether it was just for 3D drawing, or for 2D as well:
Poul: Stated that we should make the decisions at next week's meeting, in order to get more feedback from Matt and Peter Hunter.
Andre: Queried whether our "planning" document will be used by the CMISS group, and if so, whether they should be informed.
- Poul suggested that it would be good if CMISS would use CellML decisions, and vice-versa. He would be happy for others with an interest in the document to add to the document.
- There was consensus that we should send a post to the CMISS mailing list, informing them of the "planning" document.
Carey: Noted that there was debate about who our tools are targeted at: people at the institute, or lay biologists.
- Poul thinks that our work should be aimed at those within the institute, but we could accept work from outside.
Poul: Believes that some level of integration between tools is important in the long term.
Andre: Queried whether we should be developing our own in-house tools, or working with external software vendors to encourage them to support CellML.
- Poul thinks that this wouldn't work for CellML editors, because CellML concepts like imports are absent from other specifications.
- Poul was concerned we might lose control of the functionality(for example, to integrate Sarala's work) if we have to work through vendors to get changes accepted.
- Andre suggested that we do not have the resources to help all vendors, and suggests we consider COR.
- Carey noted that currently most software at the institute is developed in-house, and so this would diverge from the precedent.
- Andrew noted that most of this software is closed source, and so if we don't provide an open source implementation, there will be no open source implementation.
- Consensus was that most users don't care if it is closed source, given that most tools currently in use are closed source, and that higher adoption is more important.
- Poul noted that if we have no implementation experience, we will have difficulty helping third parties.
- Shane suggested that we should use the CellML API from CMISS as soon as possible.
- Andrew suggested that we should make service/libraries providing functionality(such as code generation), so that tools are only a thin wrapper around these. Consensus was reached on this, and that Andrew and Andre should work together to write CellML to C/FORTRAN code. Some discussion of how much of the code can be shared between languages.
Shane: Expressed concern about the idea of starting fresh on the CellML editor, given the past work put into it.
- Poul noted that starting fresh could allow us to avoid past design mistakes.
Dong: Noted that there were differences in the asthetic look between Java and Mozilla, and stated that he prefered the Java look.
- Andrew disagreed, because Mozilla's default look is to emulate the platform on which it is hosted, which is a good thing, but can be configured for different styles. Andrew doesn't believe that asthetics are very important in the decision.
- Carey and Poul agreed that asthetics are unimportant in the decision process.
Poul: Noted that he believes we should use the CellML API internally, as we want to demonstrate to others outside the institute that it is usable, and our use(or non-use) of it internally will affect the credibility of that claim.
Poul: Queried the meaning of Carey's comments in the "planning" document about browser independence(in response to Andre's comments).
- Carey noted that the decision to use the Mozilla toolkit means that we can easily switch to XULRunner, and so we are not tied in to using the browser. Therefore, he doesn't believe that the browser independence issue is a long-term "con".
Shane: Asked whether there will be any difficulty synchronising the Javascript user-interface and the C++ backend.
- Andrew noted that mozCellML currently has the same separation, and currently minor UI changes don't need Javascript changes, while minor fixes to the backend don't change the interface. Larger changes need changes in both the back and frontends.
Poul: Asked why the document claims that the Javascript code for the editor would be shorter than the current Java code.
- Andrew and Dong noted that syntactic differences, the fact that Javascript is weakly typed language, while Java is strongly typed, and the fact that Mozilla allows event handlers to be set on SVG documents, all mean that the Javascript code will be shorter.
Shane: Suggested that we should have more information on the costs of development, with time estimates on how long the changes will take.
Poul: Queried what the "virtual deskop" was exactly.
- Andrew: It is code written in Javascript, built on top of HTML, which provides windowing facilities inside another window. Java provides similar facilities with Swing.
- Dong noted that Swing is supported as part of Java, whereas we need to support the virtual desktop code ourselves.
Poul: Asked about how bad the SVG really is:
- Andrew noted that SVG requires an underlying DOM representation, which is expensive for representing large amounts of data.
- Carey noted that Mozilla's SVG is currently very slow compared to other SVG implementations.
- Andre and Shane suggested that users may produce many points, and should not have to calibrate their options to get a sufficiently small number of points.
Poul: Asked about the OpenGL section of the document, and whether it was just for 3D drawing, or for 2D as well:
- Andrew noted that it could be used for both, but we currently don't do 3D graphs.
- Carey noted that canvas will likely use OpenGL eventually, via Cairo.
- Shane noted that it would still be more efficient to have more direct access to things like display lists.
Poul: Stated that we should make the decisions at next week's meeting, in order to get more feedback from Matt and Peter Hunter.