• API stability (what we tell people) #4892
  • Do the getObject() getObjects() getAnnotationLinks() methods look like they will stand the test of time? Any suggestions? Usage examples: gatewaytest/get_objects.py
  • Is it OK to say "These methods are stable, others might change" or "The connection-wrapper is stable, object-wrappers may change"? (see below)
• blitz gateway for scripting service
  • Create blitz wrapper from existing connection. #4237
  • Do we attempt to get all users of the scripting service switched to using blitz gateway?
  • Do we try to provide enough info for them to make a choice?
• blitzWrapperObject methods #4673
  • Remove unused methods?
  • Changing the extent to which we provide object wrappers:
    • E.g. I want to provide lazy-loading of plane-info #4820
    • Do I add a PixelsWrapper that is returned by imageWrapper.getPrimaryPixels()
    • This could allow someone to do imageWrapper.getPrimaryPixels().getPlaneInfo()
    • This will break anyone who has done imageWrapper.getPrimaryPixels().sizeX.val
    • Or do I simply provide imageWrapper.getPlaneInfo() - similar to imageWrapper.getChannels() or imageWrapper.z_count()
    • Similar question for adding getPlane() method - #4368
  • getattr() should always return wrapped objects?? (Ola's question) See #4897
    • E.g. imageWrapper.getPrimaryPixels() would return a BlitzObjectWrapper.
    • This would allow you to currently do imageWrapper.getPrimaryPixels().sizeX
    • BUT making this change would break a LOT of code!
    • Not sure about how hard it is to do the wrapping, picking the right wrappers etc.

Notes

API: Chris, Will, Josh

• API: standing the test of time?

  • Josh: getAnnotationLinks probably won't
  • Will: these are from all the clients (largely insight)
    • loading childs, parents, etc.
    • Josh: would need to play with it.
  • getObject only returns first
    • Josh: think there should be an exception if more than one is returned
  • Chris: probably need to promote getAnnotationLinks
    • Josh: will take a deeper look
  • What can we tell people?
    • Josh: we could keep doing things as we do, we could version the gateway (import omero.gateway2)
    • Will: we tell people
    • bigger question of the wrappers

• Blitz gateway for scripting

  • Points
    • Create blitz wrapper from existing connection. #4237
    • Do we attempt to get all users of the scripting service switched to using blitz gateway?
    • Do we try to provide enough info for them to make a choice?
  • Do this now?
  • Josh: have we reviewed the intended methods
  • Chris: if it's support by omero.client then it should be supported by the client wrapper
    • It should be a complete encompassing support
    • Will: true, to use convenience methods in gateway, you have no way to do that for scripting service
    • What you've learned of the Python API from Web doesn't apply to scripting at all.
    • Carlos: client_wrapper was born out of having glue between BlitzGateway and client
      • Could just extend omero.client?
      • Chris: could just create a BlitzGateway.
      • Carlos: BlitzGateway was outcast; but now that we're first class
        • now having 2 gateways doesn't make sense.
      • Chris: BG is basically combining omero.client and createSession arguments
      • Carlos: caveat using client_wrapper for connections will make Chris angry
        • LOTS of magic; make Chris mad
        • but if Carlos were to develop scripts, would use BG as the base
      • @@Chris: had better clean this up for release
    • Chris: Again, anything supported by omero.client should be supported by BlitzGateway
      • set host, set ports, set encryption, join existing session, etc.
  • Josh: is there a clean separation of concerns?
    • We don't want users to have to ask "Why do I have to do X?"
    • Carlos: Blitz isn't going away
    • But do we use that as a front for everyone? Yes (already decided)
    • Are we going to use morph this to client?
    • Example: no "getTables()"
  • Step (Chris)
    1. Fix constructor to encompass all of omero.client start (incl. scripts) #4237
    2. Deprecate usage of duplicated methods in omero/init.py
    3. Deprecate getAdmin...Service, and have a standardized getServiceFactory() with wrapping
       • getSession() returns a ProxyObjectWrapper
       • ServiceFactoryWrapper, meta classing to look up with methods (e.g. get/create) with proper wrapper
         • Carlos: may not need introspection
       • Change service retrieval methods in gateway to use new logic; add deprecation warnings
  • Chris: caused problems by having two objects instead of omero.client().getAdminService()
  • Josh: omero.client was intended (among other things) to hide
  • Carlos: ...
  • @@Carlos: createService results are being cached.

• BlitzObjectWrapper

  • How much do we hide the model / provide shortcuts? (image.size_x)
  • Carlos: can move most of them into IJournal
  • Chris: how hard is it to inject a wrapper?
    • Carlos: not too hard
    • Josh: would be good to reuse Ice ObjectFactory
    • Not really feasible to change object wrappers 4.3
  • Carlos: argue that some make no sense in 4.3
  • Will: when you call some methods you get unwrapped code
    • Chris: 80% solution comes back to bite us
    • Will: there's a ticket now for how to get a PixelWrapper to lazy load something from a omero.model object
    • That's probably the change to make
    • Will: you don't know what's wrapped
    • Carlos: the wrapper objects were not an attempt to cover the whole API
      • but an attempt to cover everything that Carlos was using
      • approach would be: you should never have to call .val on anything
      • if you are doing that on a pixels, then you need a wrapper
      • Carlos intended to hide the differences
  • Will: should getattr always return a wrapper
    • potentially will break stuff
    • usage outside of what's wrapped is probably quite small
    • pixels is probably most significant
    • binning also
    • we have enough to fix that

• Hour-long summary

  • Chris: we're not really getting anywhere, there's only so much we can do, and we can't break current customers
  • Josh: for me this means we don't go public for 4.3
  • Josh: could we possibly offer a simplified gateway that we intend for people to use
  • Chris: probably simpler to rewrite
    • Josh: agreed, that's the idea of omero.gateway2, but we should distance ourselves from some of omero.gateway
  • Back to list for 4.3 (see above)
    • Document clearly what's "public", "semi-public", "dangerous", and that we'll start a clean room implementation (omero.gateway2)
    • Fix BlitzGateway constructor
    • Evaluate BlitzObjectWrapper
    • listParents to return multiple parents
      • these methods are available everywhere
      • but returns null except for dataset and image
      • Carlos: there's a field "linkClass" to define what you are going to get
    • possibly also
      • fix BlitzObjectWrapper names (bite bullet)
      • get rid of getAncestry method
  • Chris: Adding anything that Ola needs functionality wise?
    • Will: nothing needed
    • Chris: plane info?
    • Will: can add that in. separate ticket. on image? or (newly created) pixels wrapper?
    • Will: When we extend helper methods, it makes sense to emulate the model