Да я верю что другие форматы лучше. Но сначала мне надо подготовить к этому все модули, а именно перевести их все на использование общих библиотек (типа alterator-sh-functions) .. сейчас идёт процесс формирования alterator-sh-functions, нужна аналогичная работа для awk.
Также есть желание ограничить количество возможных операций и тем самым устаканить структуру дерева бакенда, но для этого сначала надо просмотреть все имеющиеся (и будущие) workflow на предмет а чего мне может не хватить ... за это я пока не брался. Есть как минимум один важный для всех модуль, чей бакенд богат и нестандартен тастолько насколько это возможно - alterator-vm. Надо бы поглядеть на него, чтобы понять: эта нестандартность вынужденная необходимость или можно без этого обойтись? Про типизацию: вот на днях смотрел на constraints и долго думал ... с одной стороны хорошо бы ограничить их типами, с другой стороны всё остальное (значения по умолчанию, исключения, возможность назначить свои регекспы на строки если стандарнтых типов не хватило) тоже нужно ... пока так не смог определиться с их будущем, единственное, что пока точно планируется сделать с ними - сделать их как модуль на шине ибо сейчас они _очень_ сильно усложняют отладку. 25.03.08, Peter V. Saveliev<[EMAIL PROTECTED]> написал(а): > В сообщении от 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 > [email protected] > https://lists.altlinux.org/mailman/listinfo/devel-conf _______________________________________________ devel-conf mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/devel-conf
