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.
| Domain | Function | What's Done | To Do | Screenshots, etc. |
| OMEIS | Image server for all clients | All [http://cvs.openmicroscopy.org.uk/tiki/tiki-index.php?page=OMEIS+Implementation+Notes] specified functionality completed. Ready for deployment. | Authentication system built, needs to be integrated and tested. Tester built, just needs TIFF support | A mini-GTK+ client pulling images through OMEIS |
| Web UI ("Marinoh") | Web-based client for accessing basic OME functions | Rebuilt and [old-link http://trac.openmicroscopy.org.uk/ome/wiki/WebClient]redesigned. DataManager, Import, SVG Viewer integrated. | Deployed for user testing March 18 | See below. |
| SVG Viewer | Simple, lightweight viewer for web-based acces to OME DB | Refactored with [old-link http://trac.openmicroscopy.org.uk/ome/wiki/SvgViewer]additional features. All base functionality in place | See Wiki [old-link http://trac.openmicroscopy.org.uk/ome/wiki/SvgViewer] page | See 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 access | NA |
| DataManager Client | Java client for managing OME Projects, datasets, and Images | Ready for User | Done, ready for user testing. | See below. |
| Browser Client | Java client, especially designed for viewing data from plate-based screens. | Basic design, implementation coming | Full deployment | Available [old-link http://web.mit.edu/jeffm/www/screenshot.tiff ] here |
| Rendering Agent | Java client for supporting viewer, performs all image LUT operations, etc. | Being built, requires testing. Done by Mar 19. | Testing and integration | NA |
| VisBio | Java app for viewing multidimesional image data. | Planning for interoperability with Shoola. | NA | See the Visbio site. |
| Docs [http://docs.openmicroscopy.org.uk] Page | Developer info site | First 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 [http://docs.openmicroscopy.org.uk/] 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.
