2008-02-08 Omero Review Meeting
Attending: Alexa, Andrew, Brian, Chris, Colin, Donald, Jean-Marie, Josh, Will, Melissa (did I forget anyone?)
Agenda
- Status Report
- OMERO.server
- OMERO.insight
- Build a search widget (presented to users today)
- Working on a Metadata browser
- OMERO.importer
- Protocol Editor
- OMERO-FS
- OME-XML
- Website
- Licensing question
Notes
- server (josh)
- sessions in
- take a look at omero.client
- donald: projection script works
- gets pixels from server
- projects them
- needs some raw store to push them back
- will work on iscript service for listing services
- hibernate bug for counting
- workaround OR patch hibernate
- josh will add loadContainerHierarchy WORKAROUND
- getImages should be OK.
- server (chris)
- sending data model changes to Andrew for proofing
- working on issues with getting pixels
- client
- search
- david showing users interface to see how they interact with API
- confusion on number of results displayed
- good to know how if they want mixed results; can't handle interactive yet
- jean-marie
- j-m woring on metadata viewer (something beginning of next week)
- can start interacting with all the structured annotations
- missing functionality
- category groups / categories
- really more additions
- possible release of insight? (for bug catching)
- 2 weeks, not really stable but workable
- j-m woring on metadata viewer (something beginning of next week)
- importer
- brian + melissa working a number of small bugs
- import data function under ImportHandler and now in ImportLibrary
- all decoupled, and should be able to separate code
- will
- "OMERO.editor"
- refactoring; a bit more work for release
- colin
- something more or less running omero.fs
- slice file to define an interface between server
- possible blitz meeting for everyone who's working on OmeroPy
- next monday? no
- wednesday morning: colin, alexa, donald
- possibly integrating ice deeper into insight (rather than just gateway)
- similar implementations in different languages, but still playing to languages
- josh available but not attending
- search
- OME-XML
- various emails; only one comment on the unique ids into the files
- tag-uris
- lsids and/or uuids
- do we just offer a scheme: urn:lsid:uuid.openmicroscopy.org:<uuid>
- any of our ids can be lsid or internal id
- best practice
- hashing
- sha1 hash
- probably only important if you want to validate a tiff file
- no comments; will probably add optionally
- OME file without image data
- valid or not valid
- let's not have us discuss this
- the community/companies should decide
- question was asked back in June; user creating files alongside package
- either empty block; or a link to the file to which the metadata points
- "OMD" Open MetaData file.
- josh: +1 possibility of using our metadata
- chris: +1 passing around "all my objectives" should be possible
- andrew: but what happens when someone tries to open it in imagej??
- chris: files are currently a convention (<ome> at the beginnging) "omd","omf"?
- just changing the file format, then documentation, then use, should be ok.
- andrew: ok, but what about using a different schema?
- ilya probably against
- various emails; only one comment on the unique ids into the files
- website
- not that much done
- paper work piled up
- will get done soon
- looking at collecting all our urls
- andrew missing mtg. next week
- licenses
- gpl2/gpl3/apl
- chris(email): ignore as long as we aren't including apl code
- jean-marie: but people are looking at what we done
- chris: core difference no-patent clause and no patent clause
- this has always been a problem
- jboss is lgpl
- LOTS of apache libraries
- basically have to ignore it
- moving away from jboss? maybe, but there's hibernate
- blockers
- workaround for loadContainerHierarchy
- model changes
- getPixels()
- search API matrix
- mutablility of annotations: user just wants to update a description VS keeping a record of things
- part of the reason why we didn't have description fields originally
- make them mutable
- or make descriptions annotations
- ???
- the reason they were immutable is because of the lack of awareness of the security model
- users aren't aware of their umask, for example
- choice: remove description, update lucene, and upgrade scripts
- part of the reason why we didn't have description fields originally
- categorygroup/category: optional upgrade script?
- but will likely be completely removed from the user interface
- ola
- working on web client
- OMERO.collaboration
- demo at end of feb. @ web meeting