Personal tools
  • We're Hiring!

You are here: Home → Community → Minutes → Mini Group meetings → API unification meetings → 2011.02.28
« September 2024 »
September
MoTuWeThFrSaSu
1
2345678
9101112131415
16171819202122
23242526272829
30
 

2011.02.28

Will's summary:

  • Stateful services
    • Currently not used in truly stateful way - state only used within a single method on client (except Rendering Engine)
    • Performance / convenience maybe, but not essential
    • Propose stateless methods to cover existing functionality - rendering engine, thumbs, pixelstore, filestore
  • Stateless method count
    • Aim to make methods "less specific".
    • Return more info from more generic methods - client does more work.
    • Try to reduce method count enough to put all in single gateway service
  • Reduce Client-side code / logic
    • What does client code get us?
    • Lazy loading (potential to do this in core model objects)?
    • Hiding 'warts' of model. E.g. Image.getPixels().getSizeZ()
    • Connection Handling
    • Might not need Lazy loading if we always load appropriate graph

TODOs - see bottom of Josh's notes

Josh's notes:

Present : Will, Chris, Josh, Carlos

  • Big questions - see http://trac.openmicroscopy.org.uk/ome/wiki/Omero/GatewayApi

  • lazy loading

  • stateful services

  • one off methods all in gateway

  • time-scale, where we're headed, how much effort to put in

  • Will: since last time, ...

  • hashed things out on the wiki pages

    • get: id
    • list: get all of something
      • Chris: eid?
      • Parameters
    • find:
    • delete:
    • search:

  • annotations seem to not fit well

  • using python gateway as something sufficient to be a client

    • Java gateway uses more functionality

  • methods on connection object itself unrepresented:

    • admin, add groups
    • shares: depends on what we do with them
      • J-M: put on hold based on mini-group discussion
        • discussed in Dundee
        • concept will lose its benefit with new permission levels
        • may should wait before adding it to gateway
        • at Imperial they were using it.

  • Josh:

  • Two services: one for acting as an adminstrator, one for user?

  • Carlos: even when acting as administrator I'm still a user

  • Chris: worried about splitting calling context, making things too complicated

  • Carlos: listProjects flag "only-owned" or "all-I-see"

  • Chris: might be able to cover this with Parameters.exp() & grp()

  • Will

  • Stateless v. Stateful

    • Josh: we either need something stateful or we need state objects which get passed
    • Chris: webclient calls all the setters each time anyway.
      • trying to support stateless clients with stateful server
      • could have had these based on change(s)
    • Will: don't know how the Java client is using these
      • not using state maintained on server
      • could be handled by passing a map.
    • Carlos:
      • can't have object server-side because links can be in the future (??)
      • would have to keep state in each of the workers...
    • Will:
      • what's used stateful?
      • Josh: state needed for one local, client method call?
      • Chris: roughly accurate
      • @@No centralized synchronization which causes problems.
        • incl. no buffer re-use or other shared resources
      • clients should still close null
    • Jean-Marie
      • copy rendering settings uses the statefulness
      • RE is probably longest lived service
      • support for multiple rendering defs may also complicate matters
      • Chris: we keep hearing that clients are keeping up with state anyway
      • Jean-Marie: have to, otherwise it's unusable
      • Also discussion to merge thumbnail service and rendering engine

  • Number of methods being used

    • Image access is through ImageWrapper (currently)
    • Putting them all together could be quite large.
    • Josh: don't think there's anything fundamentally wrong with having a long interface
    • Looking at DeprecationCandidates...
      • Trying to get an idea for which methods are used (a little, a lot, not at all)
      • Even used once.
    • Chris: Have to balance "not doing exactly what I want"

  • Model hiding & Lazy-loading

    • Will: like what Carlos has done: getImage, getChannel, getColor
    • Having getSizeX on the image itself
    • Chris: those are warts in the model we need to get rid of
    • Other big warts?
    • Will: code on the client
    • Chris: big burden to implement it. replicated across all the clients.
      • there are not wrappers for some of the objects.
      • Carlos: Ola wrapped the SPW objects
      • The fact that they are wrapped gives them a lot of smarts
      • getChannels is unique to ImageWrapper
      • Would argue that that is the place to put them
      • You have lots of workflows where you need image without pixels
      • Client can handle the lazy loading.
      • That's the correct place to be.
      • Chris: none of the clients use the low-level objects, so why do we have them?
        • If we're not supporting/improving them, then
        • Carlos: wouldn't go that far.
        • There has to be a a compatible way of working in the server
        • The object-oriented method though too magic is very pythonic
        • Shouldn't have to think in Java
      • Chris: just two different styles, in wrapper objects or in gateway object
      • Carlos: point is the django-template style so don't need lots of different views
    • Summary
      • Problems we need to solve in the core objects.
      • Core objects should handle connection & model
      • Have to do a better job of solving getting data.
    • Graphs
      • Chris: Find-grainedness is not going away, or are the queries
      • Chris: have created a mess by convenience
      • Will: getDatset(id).listChildren().getCreationDate()
      • APLLC: subset of graphs can be loaded.
      • Josh: don't mind implementing lazy-loading, but need to be uniform
      • Chris: in web it may not matter since it's close to the server,...
        • but we're not sure, because web's use cases have typically been smaller (and non-HCS)
      • Chris: Would love to see a graph of the methods/objects used to access graphs
        • use 15 or 20 max. image/pixels/(logical-)channel
        • but when it's touched, then it's all used. lazy-loading doesn't help.
    • Chris: no choice but to start moving some of the lazy-loading code out of Python
      • Carlos: would love to not have to worry about lazy-loading on the gateway side
      • Chris: we could solve a lot of this
        • If all you had to think about were 3-4 things, and not every possible graph, etc.
        • ...different method names, etc.
      • Chris: lazy-loading is because it's hard to work with the model
      • Will: use Gateway.getImage() almost everywhere, but sometimes don't use pixels
        • Is it hurting me to get the Pixels when I don't need it?
        • Chris: maybe basic loading is don't load anything.
        • but could probably get rid of lazy-loading completely if we have a few well-defined graphs

  • TODOs:

  • Need binary/stateful methods on list: renderImage, getThumbnail, raw pixels, ...

  • RE will need to be reviewed (longer-term)

  • Start looking at how IAdmin can be collapsed

  • Add connection handling to GatewayApi page ("List of Orthogonal responsibilities")

    • Also: Connection handling, Exception handling, Lazy loading, Model warts, ...

  • Defined graphs which we are actually using

  • Other things missing: sudo, mgmt. methods for rendering defs

  • Define timeline

Document Actions