[Devel-conf] TODO на alterator
Stanislav Ievlev
=?iso-8859-1?q?stanislav=2Eievlev_=CE=C1_gmail=2Ecom?=
Вт Мар 25 18:52:12 MSK 2008
Да я верю что другие форматы лучше. Но сначала мне надо подготовить к
этому все модули, а именно перевести их все на использование общих
библиотек (типа 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
Подробная информация о списке рассылки devel-conf