Content
=======

Depends
Problems
Workers
Json request
URL rewriting

Depends
=======

Erlang/OTP R13B3
rabbitmq-erlang-client 2.3.1+hg20110303.1-0ubuntu2
mochiweb 2.0.0 (json parser, url manipulating)
yaws 1.88 (web server)

Problems
========

- how do we cope with the rabbit client and it's headers? Build process that
  looks great in Unix makes developer to bump ugly in Windows.
  Currently the client is an unzipped copy of the distro's package
  (rabbitmq-erlang-client, 2.3.1+hg20110303.1-0ubuntu2)
  Possible solutions:
  - let it be. Build beam files on linux, use them everywhere. The only parts
    to be changed are start/stop scripts, configs(?), etc.

- how to restart workers? By supervisor ('permanent' policy) or by handler
  ('temporary' policy).
  - permanent:
    in case of supervisor restarted workers handler must somehow know about
    its workers (to assign jobs to them, to terminate on duration).
    Either via gproc like registry or worker must report its pid (or ref, etc)
    to handler.
  - temporary:
    all the workers are started by handler and it knows about every worker.
    In case of worker's crash there is no immediate restart. So it can be
    necessary to set required values to min_workers in config.
  Currently the 'temporary' policy is used.

Workers
=======

There are two types of workers: long living and short living processes.
The start number of long lasting workers are defined in config file
in the handler section (parameter min_workers).
The max number of short living processes is also defined in handler section
of the config (parameter max_children)
Long living workers are controlled (spawn, terminate) by eworkman_handler.

Json request
============

Version 1
---------

{type: rest},
{job_info:
  {method: xxx, url: xxx}
}


Version 2 (current)
-------------------

{type: rest},
{info:
  {method: xxx,
  url: xxx,
  host: xxx,
  auth_info: see below
  params: [
    {key1: val1},
    {key2: val2}
    ]
  }
},

Supported kinds of auth_info:

- basic:
  {
    type: basic,
    user: xxx,
    password: xxx
  }

- megaplan:
  {
    type: megaplan,
    xxx: xxx
    ...
  }


Future version (draft)
----------------------

{type: rest},
{info: {
  method: xxx, # get, post, head
  url: xxx,
    # url can be:
    # scheme://user:pass@host:port/path?params - for 'get' method
    # scheme://user:pass@host:port/path        - for 'post' method
  params: [
    {key1: val1},
    {key2: val2}
    ]
  body: xxx, # for 'post' method
  timeout: nnn # milliseconds
  }
},
{run_time: # no runtime or any unknown values in it means 'now'
  now
  | at: 'yyyy-mm-dd hh:mm:ss'
  | in: nnnnn # where nnnnn means seconds
}

URL rewriting
=============

The main config can contain the following sections: handler -> url_rewrite.
The url_rewrite is a list of tuples for url rewriting.
Every such tuple can have the following fields:
  - src_type - optional. Values: none, regex. Default - none.
  - src_host_part - mandatory. Values: string, regex (see src_type). The value
    will be matched to the input (json) url. No default.
  - dst_host_part - optional. Value: string. The url which is used if
    src_host_part has matched. In case of undefined dst_host_part the original
    src_host_part is used. No default.
  - dst_host_hdr - optional. Value: string. The host which is used in the
    "Host" header. If dst_host_hdr is empty then the input json host value
    is used. If there are neither dst_host_hdr nor input host value then
    the "Host" header is omitted. No default.