Add callback methods to omero.scripts.client

[jamoore]

After discussions (Apr 12), scripts should have a mechanism for requesting more information from the user and informing the user about the current status of the script ("0.5% finished", etc.)

This will require work on the notification system (#2169)

Proposal:

 mainJobParams = omero.grid.JobParams()
 mainJobParams.name = "imageProjection" # Name of script
 mainJobParams.inputs = {"image" : omero.grid.Param(...)}

 secondaryJobParams = omero.grid.JobParams()
 secondaryJobParams.name = "z" # Name of step
 secondaryJobParams.input = {"z" : omero.grid.Param(...)}

 # Define a script which takes an image
 c = omero.scripts.client("name",\
        mainJobParams,
        callbacks = [
            secondaryJobParams
        ])

 values = c.callback(index=0, timeout = 5)
 # or
 values = c.callback(name="z", timeout = 5)

 c.progress(percent = 0.5, step = "Downloading", index = 5, total = 100)
 c.exception(exception = ex)

 # Possible future additions:
 c.checkpoint() # saves all the session items

Suggestions welcome

See:

• ​https://www.openmicroscopy.org/community/viewtopic.php?f=6&t=7544 - user using Job.message for status.

[wmoore]

Just saving these ideas from discussion...

class GetZSliceCallback(ScriptUserCallback):
        def __init__(self):
            self.values = {}
            self.params = omero.grid.JobParams()
            z = omero.scripts.Long()
            self.params.inputs = {"z":z}

        def getParams(self, current = None):
            return self.params

        def setValue(self, name, value, current = None):
            self.values[name] = value
    
    cb = GetZSliceCallbackI()
    client.waitOnCallback(cb)
    z = cb.values["z"]
    
    client.waitOnCallback(ConfirmCallback())
    client.callback(StatusCallback(percent=.5))

    ofile = client.upload(someFile, format="text/html")
    cb = HtmlCallbackI(ofile)
    client.waitOnCallback(cb)
    
    

    """
    class ScriptCallbackHandlerI(ScriptCallbackHandler):
        def handle(jobId, cb):
            
        
    ISessionPrx prx;
    ScriptCallbackHandlerI handler;
    prx.runScript(scriptId, inputsValues, timeout, handler);
    
    """

    """
    ALTERNATIVE 1.
    """
    c = omero.scripts.client("name, description",
        job_params_1,
        callbacks = {
            "roi": job_params_2,
            "t": job_params_3,
            "z": jobs_params_4
            })
    
    c.status(0.3)
    do_something()
    c.status(0.5)
    values = c.callback("z")
    do_something_else()
    c.callback("t")
    c.status(0.7)
    values = c.callback("roi")
    c.status(1.0)
    if not c.hasCheckpoint(0):
        resume
    elif not c.hasCheckpoint(1):
        resume
    else:
    c.setOutput("image", 1)
    values = c.checkpoint(1, callback="z")
    
    
    c.progress(percent=0.3, step="Downloading")
    
    for d in range(downloads):
        c.progress(percent=0.3, step="Downloading", current=d, total=downloads)
    
    c.setOutput("processed", process_downloads())
    c.checkpoint(2) 
    c.progress(percent=0.5, step="Processing", current=5, total=123)

[spli]

Out of the tickets in story #1341 this is potentially the most useful for long running scripts, which is what we've settled on for doing feature calculation (at least in the short term). Progress information is almost essential, callbacks for client feedback/choices would make the scripting UI a lot nicer.

CC: Curtis, might be useful for ImageJ work.

[jmoore]

This needs to be compared with the new(ish) omero.cmd.Handle interface: ​https://github.com/openmicroscopy/openmicroscopy/blob/v.4.4.6/components/blitz/resources/omero/cmd/API.ice#L89

That may mean that a script need only do (conceptually) getCallback().step(0,10) if a callback has been set.

[jamoore]

Referencing ticket #1341 has changed sprint.

[crueden-x]

This is a great idea. We'll be able to implement it easily in ImageJ-OMERO by leaning on the ​StatusService (and eventually the ​TaskService), once an API is in place on the OMERO side.

[crueden-x]

One minor issue to consider is to ensure the progress reporting is lenient -- I can foresee situations with ImageJ plugins where there are bugs in the algorithm's status reporting, or new subtasks get spawned by parent tasks, so progress might appear to go backwards in some cases. As long as there are no assumptions about monotonically increasing progress, it should be fine.