Альтератор изначально строился как средство кнструирования решений.
Мы хотим конструктор, из которого мы хотим получить возможность не переписывая этот конструктор получать разные решения.
Как мы планируем систему:
- сначала мы видим объекты общо: есть пользователь, он должен смотреть видео, уметь смотреть видео и т.п.
- отсюда появляется уровень конфигурации "модель"
- мы видим, что это делается через, например, добавление пользователя в группу и т.п.
- оказывается, что у нас под моделью есть множество модулей -- бэкэндов.
- далее, мы хотим возможность всем этим управлять дать пользователю
=> интерфейс
Выглядит оно так:
интерфейс
|
модель
|
модули настроек (бэкэнд)(Пример -- опущено)
В принципе, нам ничего не мешает сделать больше уровней модели.
Модули должны общаться.
Протокол: (объект параметр1 параметр2 параметр3)
Пример:
интерфейс
| (users/test action new)
модель
| (users/test action new) (groups/test action new)
бэкэнд
Все эти модули висят на некоторой общей шине, которая имеет два названия: woolus и telegraph
- интрерфейс -- lookout
- модель --
- admiral -- отвечает за то, как размножать действия
- counter-admiral -- отвечает за то, когда что нужно возвращать
- бэкэнд -- ensign
Мы получили простую систему. Её простота обманчива.
Рассмотрим пример, как на её примере можно сделать сложную конфигурацию.
Типовой случай:
- Мы захотели тонкий клиент, который может конфигурить и пользователь, и админ через веб-интерфейс.
браузер (b) | web i+b трансп. (t) | | развязка ... t | | / i socket | | a a | | e e
- Ex.2 Хотим, чтобы админ мог управлять многими системами.
i+b | ... | t t | | e e
t -- это ещё один модуль, либо модель, либо бэкенд с разных сторон, который предоставляет возможность раздачи через сеть.
- Вопрос: что с ответами?
- Ответ: за это отвечает counter-admiral, возможна даже довольно сложная логика, например, когда c-a возвр разный результат в зависимости от результатов и команды.
- Проблемы:
- что делать со сложной семантикой ответов?
- что делать с откатами?
- что делать, если откат обломался?
- получение информации о процессе (e.g. процентики)
Гоша: задача alterator -- тиражирование решений
- Вопрос: блок модель может разъединяться, чтобы в серединке её был транспорт?
- Ответ: ну, почему-бы нет? здесь модель, там модель.
Первая задача, которая была частично решена -- построение решений и реализация решений.
Вторая задача, чтобы части к нему мог писать даже человек, не знающий много языков программирования.
Программист знает sh, perl, но не хочет изучать, например, схему, на которой написан alterator.
Поэтому все модули можно делать на любом языке программирования. За исключением одного -- описание взаимодействия делается на некоем подмножестве языка scheme.
Модули общаются стандартным для UNIX способом -- через stdio.
ENSIGN
Программист:
- пишет на scheme и пользуется всеми бонусами
- пишет на чём угодно
Мы видели, что у объектов фиксированное число аргументов.
Пример
1. (/users/test action new) 2. (/users actoin list) 3. (/users action write)
- Бэкэнд "users".
- "users -l /" вываливает на stdout информацию об ошибках "users -r test" вываливает на stdout
- uid:500
- "users -l /" вываливает на stdout информацию об ошибках "users -r test" вываливает на stdout
лирическое отступление: раньше оно было сделано через FUSE, FUSE лежал между ensign и бэкэндами
В alterator используется guile.
лирическое отступление про Scheme...
number? string? boolean? number->string #t, #f, всё истина, кроме #f ( nil, 0, ... -- истина )
LOOKOUT
Нарисовать кнопку:
(button "текст")
Нарисовать метку:
(label "метка")
Нарисовать метку под кнопкой:
(vbox (button "текст) (label "метка"))
Нарисовать кнопку, которая будет писать 8 на stdout:
(vbox
(label "метка")
(button "текст" (on-click (write (+ 5 3))))
)Вебовский движок (dom/xmlhttp) сделан на этом: http://qooxdoo.sf.net
Контакты
inger at altlinux.ru
<lj user="byuth1"/>
repo: Daedalus (alterator 2)
wiki.sisyphus.ru/Alterator