[Devel-conf] TODO на alterator

[Stanislav Ievlev]

Да я верю что другие форматы лучше. Но сначала мне надо подготовить к
этому все модули, а именно перевести их все на использование общих
библиотек (типа alterator-sh-functions) .. сейчас идёт процесс
формирования alterator-sh-functions, нужна аналогичная работа для awk.

Также есть желание ограничить количество возможных операций и тем
самым устаканить структуру дерева бакенда, но для этого сначала надо
просмотреть все имеющиеся (и будущие) workflow на предмет а чего мне
может не хватить ... за это я пока не брался.

Есть как минимум один важный для всех модуль, чей бакенд богат и
нестандартен тастолько насколько это возможно - alterator-vm. Надо бы
поглядеть на него, чтобы понять: эта нестандартность вынужденная
необходимость или можно без этого обойтись?

Про типизацию: вот на днях смотрел на constraints и долго думал ... с
одной стороны хорошо бы ограничить их типами, с другой стороны всё
остальное (значения по умолчанию, исключения, возможность назначить
свои регекспы на строки если стандарнтых типов не хватило) тоже нужно
... пока так не смог определиться с их будущем, единственное, что пока
точно планируется сделать с ними - сделать их как модуль на шине ибо
сейчас они _очень_ сильно усложняют отладку.


25.03.08, Peter V. Saveliev<peet на altlinux.org> написал(а):
> В сообщении от Tuesday 25 March 2008 11:10:00 Stanislav Ievlev написал(а):
>
> > Петя, когда же ты наконец поймёшь, что alterator находится в других
>  > условиях нежели connexion. А то тебя послушаешь: сидит тут злобный
>  > Стас, как собака на сене и ничего не хочет и не даёт делать. Вот
>
>
> Извини, я был не сдержан.
>
>  <skip>
>
> > Я не могу мгновенно взять и внедрить типизацию и что-нибудь там ещё.
>  > Или одним махом взять и сделать backend4 с другим более классным
>  > протоколом и послать все модули куда подальше.
>
>
> Речь не совсем про это. Просто чем дольше живёшь на неудачной архитектуре, тем
>  тяжелее с неё слезать и тем тяжелее всем окружающим. И если бы удалось
>  договориться с типизацией и остальным ещё летом, то уже все текущие
>  разработки были бы по новой схеме, которая прожила бы дольше, чем текущая
>  реализация. Я сейчас детали не помню, прочитаю ещё раз, но летом я просто не
>  смог в рамках протокола реализовать несколько простейших вещей. И я не верю,
>  что текущий протокол бэкендов останется на века. Вот про что речь
>
>  <skip />
>
> > Понимаешь: мне надо знать не только какая клёвая штука xmlrpc или
>  > base64, а ещё как к этому прийти.
>  >
>
>
> К этому придти очень просто. Достаточно подумать о сторонних интерфейсах и о
>  сохранности данных.
>
>  Стас, поправь меня, если я ошибаюсь -- я прав, что в протоколе работы с
>  шелл-бэкендами в _данных_ надо избегать некоторых символов и/или ключевых
>  слов? Мне так казалось.
>
>  А сторонние интерфейсы -- все, что можно уже сделано, все эти xmlrpc, dbus и
>  т.п. и т.д. И библиотеки сами заворачивают данные в нужный формат, и куча
>  граблей уже отловлена.
>
>  Изобретая свой протокол, ты а) ловишь те же грабли б) сделаешь библиотеку под
>  себя, под шелл, а остальные? А остальным придётся писать свою реализацию,
>  т.к. библиотеку работы с этим протоколом под c++ и python ты ведь делать не
>  будешь.
>
>  <skip />
>
>  ЗЫ: по-хорошему, нам бы договориться о представлении дерева -- того, что у
>  connexion в корке, а у альтератора в бэкендах. На мой неискушённый взгляд,
>  одно вполне картируется на другое -- при условии интерфейса взаимодействия. А
>  типизация... ну, фиг с ней. В конце концов просто выставлю альтераторовским
>  данным тип "строка" для начала, а там посмотрим.
>
>
>  --
>
> Peter V. Saveliev
>  _______________________________________________
>  devel-conf mailing list
>  devel-conf на lists.altlinux.org
>  https://lists.altlinux.org/mailman/listinfo/devel-conf