Personal tools
  • We're Hiring!

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

2011.04.07

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