[devel] Q: future of alterator backends

[devel] Q: future of alterator backends

[Stanislav Ievlev]

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.

Re: [devel] Q: future of alterator backends

[Anton Farygin]

28.10.2009 21:35, Stanislav Ievlev пишет:

>
> 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

Стас, а если foo, bar, ipv4-address и hostname надо получать из 
медленного источника, то не получится ли замедления - нам ведь придётся 
проинициализировать все эти значения _одновременно_ ?

Re: [devel] Q: future of alterator backends

[Mikhail Efremov]

On Wed, 28 Oct 2009 23:11:07 +0300 Anton Farygin wrote:
> > 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
> 
> Стас, а если foo, bar, ipv4-address и hostname надо получать из 
> медленного источника, то не получится ли замедления - нам ведь
> придётся проинициализировать все эти значения _одновременно_ ?

Нет, если я правильно понял мысль Стаса - это просто инициализация
именами. Реальный вызов функции foo произойдет только когда будет вызов
(woo-call "/backend/foo" arg1 "value1" arg2 "value2") из клиентского
кода.
В целом все это позволит выкинуть одинаковый, повторяющийся
в каждом бакенде код. Так что мне нравится :)

-- 
WBR, Mikhail Efremov

Re: [devel] Q: future of alterator backends

[Anton Farygin]

29.10.2009 00:33, Mikhail Efremov пишет:
> On Wed, 28 Oct 2009 23:11:07 +0300 Anton Farygin wrote:
>>> 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
>>
>> Стас, а если foo, bar, ipv4-address и hostname надо получать из
>> медленного источника, то не получится ли замедления - нам ведь
>> придётся проинициализировать все эти значения _одновременно_ ?
>
> Нет, если я правильно понял мысль Стаса - это просто инициализация
> именами. Реальный вызов функции foo произойдет только когда будет вызов
> (woo-call "/backend/foo" arg1 "value1" arg2 "value2") из клиентского
> кода.
> В целом все это позволит выкинуть одинаковый, повторяющийся
> в каждом бакенде код. Так что мне нравится :)

Если так, то конечно хорошо.

Стас, может быть сразу подумаешь над тем, как делать обработку больше 
чем одного уровня в дереве ?

foo/faa/fuu
bar/bor/bur

особенно это интересно для тех случаев, когда содержимое foo зависит от 
окружения, т.е. - динамически изменяется.

Re: [devel] Q: future of alterator backends

[Mikhail Efremov]

On Thu, 29 Oct 2009 09:16:12 +0300 Anton Farygin wrote:
> Стас, может быть сразу подумаешь над тем, как делать обработку больше 
> чем одного уровня в дереве ?
> 
> foo/faa/fuu
> bar/bor/bur

/backend/foo в предложенной схеме означает "функция foo в
бакенде backend". Что должно означать в этом случае foo/faa/fuu я не
понимаю. В общем случае это можно заменить на вызов функции foo с
аргументами faa и fuu:
(woo-call "/backend/foo" arg1 "faa" arg2 "fuu").

> особенно это интересно для тех случаев, когда содержимое foo зависит
> от окружения, т.е. - динамически изменяется.

Я не понял о чем тут. Стас же сказал - это RPC. О каком динамическом
изменении речь?

P.S. Это ничего, что я не про языки?

-- 
WBR, Mikhail Efremov

Re: [devel] Q: future of alterator backends

[Anton Farygin]

29.10.2009 15:29, Mikhail Efremov пишет:
> On Thu, 29 Oct 2009 09:16:12 +0300 Anton Farygin wrote:
>> Стас, может быть сразу подумаешь над тем, как делать обработку больше
>> чем одного уровня в дереве ?
>>
>> foo/faa/fuu
>> bar/bor/bur
>
> /backend/foo в предложенной схеме означает "функция foo в
> бакенде backend". Что должно означать в этом случае foo/faa/fuu я не
> понимаю. В общем случае это можно заменить на вызов функции foo с
> аргументами faa и fuu:
> (woo-call "/backend/foo" arg1 "faa" arg2 "fuu").

Если представить функции backend'а как каталоги, а аргументы - как 
файлы, то /backend/foo/faa/fuu должно означать файл fuu в подкаталоге 
faa в каталоге foo.

>
>> особенно это интересно для тех случаев, когда содержимое foo зависит
>> от окружения, т.е. - динамически изменяется.
>
> Я не понял о чем тут. Стас же сказал - это RPC. О каком динамическом
> изменении речь?

Вот о том и вопрос, что хотелось бы? получить динамическое изменение 
функций. Я же ещё помню alteratorfs через fuse.

>
> P.S. Это ничего, что я не про языки?

Нормально.

Re: [devel] Q: future of alterator backends

[Stanislav Ievlev]

29 октября 2009 г. 17:56 пользователь Anton Farygin
<rider@altlinux.com> написал:
> 29.10.2009 15:29, Mikhail Efremov пишет:
>>
>> On Thu, 29 Oct 2009 09:16:12 +0300 Anton Farygin wrote:
>>>
>>> Стас, может быть сразу подумаешь над тем, как делать обработку больше
>>> чем одного уровня в дереве ?
>>>
>>> foo/faa/fuu
>>> bar/bor/bur
>>
>> /backend/foo в предложенной схеме означает "функция foo в
>> бакенде backend". Что должно означать в этом случае foo/faa/fuu я не
>> понимаю. В общем случае это можно заменить на вызов функции foo с
>> аргументами faa и fuu:
>> (woo-call "/backend/foo" arg1 "faa" arg2 "fuu").
>
> Если представить функции backend'а как каталоги, а аргументы - как файлы, то
> /backend/foo/faa/fuu должно означать файл fuu в подкаталоге faa в каталоге
> foo.
Может быть когда-нибудь так и будет. Пути к объектам применяются также
в dbus, так что в будущем должно быть относительно просто пробросить
все бакенды и в эту шину.

Re: [devel] Q: future of alterator backends

[Stanislav Ievlev]

29 октября 2009 г. 0:33 пользователь Mikhail Efremov <sem@altlinux.ru> написал:
> On Wed, 28 Oct 2009 23:11:07 +0300 Anton Farygin wrote:
>> > 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
>>
>> Стас, а если foo, bar, ipv4-address и hostname надо получать из
>> медленного источника, то не получится ли замедления - нам ведь
>> придётся проинициализировать все эти значения _одновременно_ ?
>
> Нет, если я правильно понял мысль Стаса - это просто инициализация
> именами. Реальный вызов функции foo произойдет только когда будет вызов
> (woo-call "/backend/foo" arg1 "value1" arg2 "value2") из клиентского
> кода.
> В целом все это позволит выкинуть одинаковый, повторяющийся
> в каждом бакенде код. Так что мне нравится :)
Да, конечно. Кроме того появляется возможность видеть структуру бакенда ;)
alterator-cmdline --help foo выдаст все имеющиеся функции ;)

Re: [devel] Q: future of alterator backends

[Stanislav Ievlev]

28 октября 2009 г. 23:11 пользователь Anton Farygin
<rider@altlinux.com> написал:
> 28.10.2009 21:35, Stanislav Ievlev пишет:
>
>>
>> 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
>
> Стас, а если foo, bar, ipv4-address и hostname надо получать из медленного
> источника, то не получится ли замедления - нам ведь придётся
> проинициализировать все эти значения _одновременно_ ?
Типы потом переедут в декларации функций, если ты об этом.