[IPOL discuss] how to specify "run_proc" in the demo generator (and wait/run/result in the demos)

[Nicolas Limare]

>    a) In "run_algo." This function makes calls to the compiled code.
> The code of this function depends on (and it is different) each
> demo.
> 
>    b) In the "wait". Some demos apply some operations over the input images.
> 
>    c) In the "result" or "run_algo" (depending on the demo). Some
> demos apply some operations on the output images (such as invert the
> image, resize, etc).

I think the general pattern could be
* in wait(): check the parameters and return the "wait" redirection page
  We want to see the "wait" page as soon as possible, and nothing can
  be done one the "wait" page has been sent because the browser will
  immediately call the run() method. We also want to be sure that once
  we go for run(), there won't be a parameter error.
* in run(): do everything, pre-processing, call the binaries,
  post-processing
  My initial choice to split run() and run_algo() was a bad decision,
  it is completely useless after one year of demo development, and
  inly adds to the complexity.
  In term of stupid acromyms, KISS & YAGNI[1].
* in result(): do nothing, do not modify any data, only show the data.
  Some users will reload this page, the result must keep the same
  after mutiple page reload ie result() must be nilpotent ie result()
  must not modify the data.

[1]http://en.wikipedia.org/wiki/KISS_principle
   http://en.wikipedia.org/wiki/You_ain't_gonna_need_it

I know some demos, including mine, don't follow these rules, but we
can decide on some rules, and slowly converge.

>    In my opinion, the demo complexity is in how the algorithm calls
> the binaries to execute. [this] is difficult to know (and specify).

I completely agree, that's the very complex part.

>    (1*) The user must create three files to be included in the
> "app.py" file with a <%include file="file1.py" />.
>    (2 *) All the processes are called through a script created by
> the algorithm author.

I want to suggest a third option:

    (3*) Since the precise understanding of how to call the programs
  is too complex to be managed with a web interface ans a set of
  pre-defined forms, don't try to do it with the demo generator
  because it will never be correctly done. Only provide an option for
  the simplest case (one binary, no parameters, input file, output
  file), and generate an app.py code containing an empty space to be
  filled by the demo author if they want something else.
  Except for the very simple case, the demo generator would generate a
  demo draft, to be finely tuned by the demo developpers.
  To keep the tuning in another file, we could, instead of
  <%include file="file1.py" /> (mako syntax), use the simple python
  module import and function redefinition:

    class app(base_app)
       ....
    # run() is defined in local.py
    from local import run as local_run
    # redefine app.run()
    app.run = local_run
   
-- 
Nicolas LIMARE - CMLA - ENS Cachan    http://www.cmla.ens-cachan.fr/~limare/
IPOL - image processing on line                          http://www.ipol.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20110825/2be40ced/attachment.pgp>