[devel] I: alterator internals

* [devel] I: alterator internals - 5
@ 2005-06-27 12:15 Stanislav Ievlev
  2005-06-27 16:46 ` Alexey Voinov
  2005-06-28 10:32 ` [devel] " Anton Farygin
  0 siblings, 2 replies; 5+ messages in thread
From: Stanislav Ievlev @ 2005-06-27 12:15 UTC (permalink / raw)
  To: devel

[-- Attachment #1: Type: text/plain, Size: 6290 bytes --]

Продолжение истории...

3.  Первый модуль

Мы уже узнали достаточно чтобы попробовать написать свой первый модуль для
alterator. Так что не будем медлить с долгими рассказами, и сразу же
приступим к делу. Я пока не буду давать лишних комментариев, и объяснять
что и почему, просто смотрите как это сделать и всё ;)

Если формат backend'a покажется вам несколько странным, то объясню - он
был изначально рассчитан на существование в виде модуля для виртуальной
файловой системы - admfs. Сейчас она не используется - а формат остался
... может в будущем мы вернёмся к этой идее, уж больно она красивая.

Для того чтобы создать простейший модуль для alterator, надо:
1. написать низкоуровневую часть - backend, которая собственно и будет
крутить ручки в системе
2. написать интерфейс 

Давайте сделаем модуль, который позволит выбирать пользователю локаль в
системе.

3.1 Устройство backend.

Интерфейс и backend будут обмениваться между собой посредством команд
фиксированного формата: "<объект> <действия>".
Объект принято именовать так же как и объекты в файловой системе, то есть
последовательность слов, разделённых символом '/'.

Например:
/users/root
/network/interfaces/eth0

Первая часть имени совпадает с именем файла бакенда.

Например
/users/root - файл backend, называется users
/network/interfaces/eth0 - файл backend называется network

Оставшаяся часть имени передаётся backend и он дальше сам разбирается с
тем что с ней делать.

Действия есть последовательность атрибутов со значениями, один атрибут
имеет особое значение, зовут его action. action - собственно означает
какое действие мы можем предпринять над объектов.

Возможные значения action:
read - прочитать атрибуты объекта
write - изменить некоторые атрибуты объекта
list - получить список объектов которые данный содержит (аналогично ls в каталоге)
new - создать объект
delete - удалить объект

Атрибут action всегда должен присутствовать в команде.

Например:

/users/test action=new uid=506 gecos="Some User"
(создать пользователя тест с UID 506 и комментарием "Some User")

/network/interfaces/eth0 action="read"
(считать параметры интерфейса, например ip-адрес,шлюз etc.)

Этот язык общения со времён первого alterator носит странное имя WOO.

В нашем случае мы имеем следующие объекты:

/i18n/current - текущее значение локали
/i18n/available - установленные в системе локали
...
/i18n/available/Russian locale for Russia - например одна из локалей в системе.

Как можно догадаться, i18n - это будет имя нашего файла - backend'a.

/i18n/current будет иметь следующие атрибуты:
stdname - стандартное имя локали без кодировки, например "ru_RU"
title - описательное имя локали, например "Russian locale for Russia"
charmap - кодировка, например "KOI8-R"

stdname.charmap - даёт стандартное системное имя, которое обычно
содержится в переменной LANG, в нашем случае это ru_RU.KOI8-R.

Можно было бы сделать один атрибут lang, но удобнее держать отдельно
кодировку.

Чтобы считать текущее значение, команда следующая:
/i18n/current action=read
Чтобы записать новое значение переменной LANG, команда следующая:
/i18n/current action=write lang=ru_RU.KOI8-R

Как видите атрибуты на чтение и запись не обязаны совпадать. Может это не
совсем идеологически верно, зато удобно.

3.1.2 Пишем backend.

С языком общения мы вроде как разобрались, теперь собственно формат
backend.

backend - это обычное приложение, написанное на произвольном языке
программирования, который откликается на внешние раздражители следующим образом:

*(action=read)* backend -r объект - выдать на stdout, атрибуты и их значения в формате:
атрибут1:значение1
атрибут2:значение2
....
(соответственно имя атрибута не должно содержать двоеточия - это не очень
сильное ограничение)

объект - это хвост имени объекта, с отрезанным именем backend.
Так "a/b/c/d" - урежется до "b/c/d".

Например: (для woo-команды: /i18n/current action=read)
	$ ./i18n -r current
	stdname:ru_RU
	title:Russian locale for Russia
	charmap:KOI8-R

	$ ./i18n -r "available/Russian locale for Russia"
	stdname:ru_RU
	charmaps:CP1251,IBM866,ISO-8859-5,KOI8-R,UTF-8

*(action=list)* backend -l объект - выдать на stdout список подобъектов в формате
"имя[пробел][r|d]" где d ставится рядом с объектом, содержащим другие
объекты, а r - рядом с обычным объектом.

Например: (для woo-команд: /i18n action=list и /i18n/available action=list)
	$ ./i18n -l /  
	available d
	current r

	$ ./i18n -l available
	Russian locale for Russia r
	Russian locale for Ukraine r

*(action=write,new)* backend -w объект - принять с stdin параметры в виде "атрибут:значение" и записать их в объект.

Например: (для woo-команды: /i18n/current action=write lang=ru_RU.CP1251)
	$echo "lang:ru_RU.CP1251"| ./i18n -w current

Отдельной команды для action=new нет, backend сам в состоянии догадаться,
делать ему новый объект или модифицировать имеющийся.

*(action=delete)* backend -d объект - удалить указанный объект

Ну вот собственно и весь формат backend.

Пример скрипта на shell, который всё это реализует приложен к письму.
Думаю что вы легко сможете написать и свою версию, возможно даже более
правильную и корректную ;)

3.2 Опять про Scheme: Локальные переменные

Проведём небольшое усовершенствование своих познаний по Scheme.

В Scheme в отличие от Common Lisp применяется привычный подход к понятию
локальности (так называемый "Lexical Scope" против "Dynamic Scope" в Common Lisp):

* Переменные определённые внутри некоторой функции видны во всех функциях,
  определённых внутри данной, но не видны вне её.

	(define a 3)

	(define (f)
	   (define b 4)
	   (define (g)
	      (write b)) ; мы видим эту переменную так как g сама определена внутри f
	   (g)
	   (write a) ; мы видим эту переменную ибо она в охватывающем окружении
	   (write b)) ; это наша локальная переменная
	(write b) ; ошибка a - определена внутри f и не видна на вышестоящем уровне.

* Локальные переменные затеняют глобальные:
(define a 3)
(define (f)
	(define a 4)
	(write a))
(f) ; будет напечатано 4, а не 3, так как локальная переменная затенила глобальную.

Параметры у многоаргументных функций, суть локальные переменные со всеми
вытекающими последствиями:

(define x 4)
(define (f x)
	(write x))
(f 5) ; будет напечатано 5, а не 4 ибо x - локальная переменная в функции f.

--
Продолжение следует ...

[-- Attachment #2: i18n.bz2 --]
[-- Type: application/x-bzip2, Size: 1508 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread