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
  • 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

• 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

• 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
  • 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