2011.03.14

Notes by Josh: (Will, Carlos, Chris, Josh)

• Short-term use of omero.gateway

• when?

• what to hide?

• entry point for everyone?

• Model unification issues

  • Chris: General thought - bad form and gets us into trouble later
  • Some places it might make sense, but image.z_count gets us into trouble
  • J-M: agrees with Chris
    • Changing the model is not going to happen soon; unknown even if we need Pixels
    • But at least z_count should be getSizeZ
  • Carlos: (even being the one to blame) concur. Should follow the model
    • Should be as consistent as possible
    • re: simplifcation, we need proxying methods for working from django templates
    • Will: getSizeZ v. getPrimaryPixels().getSizeZ would be ok.
    • Carlos: but you have no control over loading
    • Will: but if the gateway only handled loading
    • Carlos: main purpose is to handle the connections.
    • All method wrapping would be moved to django web gateway
    • But it's useful to have it even when debugging it from the shell
    • Chris: can we get an exhaustive list of the simplifications so we can evaluate them?
    • the examples we have are easy to do currently (with existing API)
    • could add some things to the API:
    • getChannelName ... on the model object
    • Josh: that could get quite complicated.
  • Will: for 4.3?
    • Chris: we're not going to get away from people using this
    • If we make modifications (remove z_count), will need to deprecate and list alternatives before 4.3 is RC.
  • Jean-Marie:
    • Size should be moved up to the Image

• Long-term / service&api

• IContainer, IQuery, and IMetadata (minimally in IAdmin) used for loading graphs

• ObjectGraphs page summarizes all the IQuery queries that Will could find.

• Something inbetween IContainer and IQuery

  • More flexible (especially for loading and filtering)
  • Trying to keep the number of methods lower.
  • Perhaps this is too ambitious.
  • Chris
  • Problem is building another query language
  • People don't want to learn a query language
  • Josh: agreed. But to solve the backwards compatibility issue
  • Chris: want to reduce develop overhead

• Have to rationalize the names we use in the HQL

  • Which names? Class names don't match field names in HQL.
  • Have to do this eventually.

• Summarizing:

• Chris: First goal is to get developers started fast

• Josh: Other goals: LTS (long-term support) and not too many methods

• Will: 4.3 goal would be to say that gateway is usable.

  • Josh: that doesn't change the 3 issues we have to solve
  • Chris: if we could push down some key methods, we could simplify things a good deal
  • Put graphs in Parameters object...
  • Trying to find a half-way house.

• Annotations

  • Josh: May also want to fix bi-directionality of annotations
  • Chris: now is the time to fix the warts in our API
  • define a few methods for handling annotation querying

• Unused methods

• IRenderingSettings can almost all go (perhaps even without deprecation)

• IPixels, IMetadata as well; largely unused.

• Pick time and do it on a service by service method.

• Need to get do several short blocks of all of us going over things

  • "Who uses IAdmin.canUpdate()" "Vote to remove it: against?"

-TODO:

• List where blitz gateway methods differ from model. E.g. image.getSizeZ() vv image.z_count() etc

• Provide correct methods with same names as model

• Deprecate / remove? 4.2 methods and document where functionality now lies

• Implement 'generic methods' from http://trac.openmicroscopy.org.uk/ome/wiki/Omero/GatewayApi in blitz gateway

  • getObjects("Image", ids)
    • this is already there - needs to support all types (not just P/D/I)
    • use iQuery to load graphs etc. Default is queryService.get("Instrument", iId) etc.
    • should load more rather than less (loading is cheap compared with multiple calls)
  • listObjects("Image", params)
  • findObjectsByAttribute("Image", 'name', 'myImage')
  • listAnnotations("Image", "Tag", ns='blah') # new method - needs thought!
  • delete and search already have generic methods. Suitable as they stand?

• Remove all methods where functionality can be covered by generic methods

  • Maybe move these 'convenience' methods to webclient_gateway if needed
  • Update webclient to use generic methods
  • Try to do all the above by 4.3!

• Add new 'generic methods' to query service.

  • Now, blitz gateway functions can simply delegate to iQuery.
  • Blitz gateway methods simply handle wrapping objects.