Personal tools
  • We're Hiring!

You are here: Home Community Minutes Meetings March 2004 meeting: Summary

March 2004 meeting: Summary

OME Status: March 15, 2004

Our current goal is the production and release of a suite of clients, leveraging the web and Java remote capabilities, to proote use of OME infrastructure. First internal release is scheduled for March 15, 2004. External release April 15, 2004.

Progress on this release started mid-November 2003. Currently, we are ~10 days behind schedule. Expected internal release March 27, 2004. External release April 27, 2004.

The OME project is divided into a series of different domains. This table summarizes status of the different domains relevant to the upcoming release.

DomainFunctionWhat's DoneTo DoScreenshots, etc.
OMEISImage server for all clientsAll [] specified functionality completed. Ready for deployment.Authentication system built, needs to be integrated and tested. Tester built, just needs TIFF supportA mini-GTK+ client pulling images through OMEIS
Web UI ("Marinoh")Web-based client for accessing basic OME functionsRebuilt and [old-link]redesigned. DataManager, Import, SVG Viewer integrated.Deployed for user testing March 18See below.
SVG ViewerSimple, lightweight viewer for web-based acces to OME DBRefactored with [old-link]additional features. All base functionality in placeSee Wiki [old-link] pageSee below.
Remote Framework ("Shoola")API to OME for remote clients"95-100%" done. Complete testing suite available. Access to ST's avalable.Resolve row create issues. Testing of ST accessNA
DataManager ClientJava client for managing OME Projects, datasets, and ImagesReady for UserDone, ready for user testing.See below.
Browser ClientJava client, especially designed for viewing data from plate-based screens.Basic design, implementation comingFull deploymentAvailable [old-link ] here
Rendering AgentJava client for supporting viewer, performs all image LUT operations, etc.Being built, requires testing. Done by Mar 19.Testing and integrationNA
VisBioJava app for viewing multidimesional image data.Planning for interoperability with Shoola. NASee the Visbio site.
Docs [] PageDeveloper info siteFirst version up, reasonable amount of docs.Flesh out How To's. XML and Shoola docs needed. Integration of much of Tiki docs, but not till after external release.See [] here.

Screenshot of Web UI "Marinoh"

picture not found img/wiki_up//marinoh1_small.jpg

Screenshot of SVG Viewer

picture not found img/wiki_up//Pic001.jpg

Screenshot of DataManager Java Client

picture not found img/wiki_up//shot_3.jpg

Screenshot of Image Browser

picture not found img/wiki_up//screenshot.jpg

Proposal for policy for building and testing.

This is result of conversation between Dundee and NIH groups. Is only a draft-- please comment as necessary.

First draft March 17, 2004 JRS

0) We freeze code to all new features about 2 weeks before external release. ER is scheduled one month after internal, which looks to be about March 27 (see tiki, "March Status Report" for details). This freeze stays in place til about 2 weeks after release. Our efforts during this time go to bug fixes. ("Does this amount of time make sense?")

1) Weekly builds. These take place as before. Chris does these at some specified time, TBD. These weekly builds are tagged, and released on CVS.

2) To minimize work required on weekly builds, we institute a daily build and test system. The goal here is to establish whether the previous day's commits break anything critical in the system. The exact test specifications are being drafted by Josiah and will be posted. Ilya is in charge of implementing daily tests, and will explore automating Josiah's specifications to minimize time requirements. The goal of daily builds is only to establish that system compiles, installs, builds, and runs standard set of tasks (likely login, import, project create, etc.). Logged output from tests will identify problem-- person repsonsible must fix. This obviously suggests a full testing suite, which we will need to develop, but after April.

3) Builds will be tested on fedora and OSX.

4) A bug tracking system is put into place. Do we go with bugzilla, or use Sourceforge? Only problem with SF is identity. Would save us time, but our own means more control.

Document Actions