2005-02-07 Baltimore, Dundee, Madison

Attending: Harry, Jean- Marie, Andrea, Curtis

Dundee is currently working on the browser. Lots of work has been done that is not in CVS. Completion of the browser is the last major task before the release.

Before release, appropriate license files must be added to the distribution. Specifically, for cod e that was not written in-house, license files must be added. Harry will send Andrea necessary information for taking care of this with respect to code used in the chainbuilder and zoomable browser. There maybe a few license files that need to be added.

A release candidate is planned for 17 or 18 February. This will include the chainbuilder and zoomable browser. Harry will provide (potentially minimal) documentation for these tools by 17 Feb.

The release will provide two binaries: an OS X-specific app, and a generic distribution for other platforms. - end of next week. release candidates - Feb 17 or 18.

Shoola seems to work on systems running JDK 1.5. Building on 1.5 works fine (see next item), and the agents seem to run. However, no formal testing has been done to verify that all agents work properly. Binaries provided in the release will indicate that Shoola might run against 1.5, but all testing has been done against 1.4, so there may be difficulties.

This build system uses a jar file to set up all of the build dependencies transparently, freeing the developer from having to manually configure their environment with the proper versions of the various external jars. Furthermore, this tool can be used to build Shoola on machines that are only equipped with the java run-time environment (and therefore do not have the java software development kit). This build file makes building simpler, but it introduces an extra indirection and possibly raises some licensing issues (described below).

In constructing the build jar file, the build system makes use of a sunjdk-tools jar file. We don't currently know if this jar file can be redistributed. Andrea will investigate. If licensing terms prohibit redistribution, we might have to go back to straight use of the jar file. This would mean that developers would have to put in the extra effort to appropriately configure their ant environments.

Andrea and Jean-Marie have been working on some of the shortcomings of OME-JAVA as they impact rendering. The OME-Java code calls upon Apache's commons-httpclient jar to make any HTTP calls to OMEIS. Unfortunately, commons-httpclient is sub-optimal, as it makes many small memory allocations, and does not handle the very large buffers that might be needed to handle stacks of planes. A short-term workaround is to bypass OMEIS calls in OME-JAVA, in favor of having Shoola make direct calls to OMEIS. That is what is being done now.

It might be possible to improve the performance by going straight to the socket stream in the commons client, and then allocating a buffer, but it is not clear if this will solve all problems.

The short-term (immediately post-release) plan for improving performance is to move compositing and image construction code onto the server side, with code that will interact with OMEIS. This will allow memory-intensive operations to be done on the server, thus reducing image transfer. For example, imagine an image with 4 wavelengths. Currently, a plane is loaded to the client for each wavelength, and those planes are combined to create an image. If this code were moved to the server, the resulting image could be constructed ''before" any data is transferred. Thus, one image can

be sent, instead of 4 planes.

The Code Freeze that was discussed is not a global ban. Instead, it is just an explicit acknowledgment of the limits on resources. Andrea and Jean-Marie will not have the time to make changes to OMEDS, as they will be focusing on implementation of rendering code in the server. Changes that others make are OK, as long as they don't break other code.

That said, it is often difficult to tell when changing a call will have an impact. Since Shoola does not have a full regression test, changes may have impacts that go unnoticed. Thus, care must be taken.

Communciation of plans and intent to the group might help identify situations where regression errors might creep in.

Discussions on the possibility of having Josh join the Dundee group are ongoing. Josh would be working on exploring the possibility of extending the Shoola data model to use OWL and RDF. These expressive frameworks would let OME express relationships that are difficult to present with Semantic Types. Furthermore, use of these ontologies would help integration with GO and other existing biological ontologie.

As Josiah is interested in this topic as well, he would be involved in any such discussions.

OME-JAVA is acknowledged to have some real shortcomings. However, there are currently no resources available for refactoring, so any improvements will be tabled.

OME-JAVA is not going away any time soon. Curtis, Zach, and others need not worry about code disappearing from underneath them .

Jean-Marie and Andrea have done some performance testing. However, their efforts have been limited to the HTTP client issues described above.

Client Architecture

Andrea has proposed ideas for making caching and multi-threading more easily available to Shoola clients. However, these ideas are very preliminary and will not be implemented any time soon.

Eventually, Shoola will move to a plug-in architecture. Details of this transition will need to be discussed. Eclipse provides support for UI facilities, and a common framework, but transition costs may be high, and the exact benefits are unclear. Alternatively, transition to a simpler plug-in model should be possible with a relatively small (~ 2 weeks) effort. Evaluation will be needed.

We agreed that another call in 2 or 4 weeks will not be needed. Instead, we should plan on at least 1/2 day for java development discussion at the March meeting, and then perhaps monthly calls after that.