[devel] Q: future of alterator backends

[Stanislav Ievlev <stanislav.ievlev@gmail.com>]

Greetings!

This is a proposal of a new alterator features. Your comments are welcome ;)

alteratord service is going towards a RPC model.
At the first stage, I'm planning to replace a single message handler
with a several "export" instructions.

Current backend:
--
alterator_api_version=1

. alterator-sh-functions

...

message_handler()
{
  case "$in_action" in
    type)
     write_type_item a ipv4-address
     write_type_item b hostname
     ;;;
    foo) foo ;;
    bar) bar ;;
    ...
  esac
}

message_loop
--

New style backend will look like:
--

alterator_api_version=1

. alterator-sh-functions

....

alterator_export_var a ipv4-address
alterator_export_var b hostname

alterator_export_proc foo
alterator_export_proc bar

message_loop
--

Current backend call from client's code:
--
(woo-read "/backend" action "foo" a "value1" b "value2")
...
(woo-read "/backend" action "bar" a "value1" b "value2")
--

New style backend call from client's code:
--
(woo-call "/backend/foo" arg1 "value1" arg2 "value2")
(woo-call "/baclend/var" arg1 "value1" arg2 "value2")
--

All other processing (global "in_" variables and functions to send
answer from backend) and underlying protocol remains without changes
at this stage. This allow us to prepare all existing code for the
subsequent transformations.

At the next stage I will replace a global incoming variables "in_"
with a usual function arguments.

--
With best regards
Stanislav Ievlev.