Personal tools
  • We're Hiring!

You are here: Home Community Minutes Mini Group meetings API unification meetings 2011.03.14

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.
Document Actions