Петя, когда же ты наконец поймёшь, что alterator находится в других условиях нежели connexion. А то тебя послушаешь: сидит тут злобный Стас, как собака на сене и ничего не хочет и не даёт делать. Вот глядите как я клёво придумал и как тут у них всё криво. Я хочу их спасти, а они упорно отказываются.
Протокол бакендов был сделан очень и очень давно, тогда и мысли были другими и задачи стояли иные. Модули писались и будут писаться постоянно - ибо встают разные задачи. Я не могу мгновенно взять и внедрить типизацию и что-нибудь там ещё. Или одним махом взять и сделать backend4 с другим более классным протоколом и послать все модули куда подальше. Иногда чтобы сделать одну простую вещь надо предварительно подготовить с десяток других мест, подтянуть в Сизифе с десяток модулей. Как только где-то возникает готовность к изменениям - я сразу начинаю это обсуждать. А сейчас и всё TODO стало полностью публичным. Вот лучше бы почитал его и подумал бы какое выбрать направление движения, какие нюансы надо ещё прояснить, чтобы оба проекта взаимно обогащали друг друга, а не разбегались. Понимаешь: мне надо знать не только какая клёвая штука xmlrpc или base64, а ещё как к этому прийти. 24.03.08, Peter V. Saveliev<[EMAIL PROTECTED]> написал(а): > В сообщении от Monday 24 March 2008 16:14:39 Vitaly Ostanin написал(а): > <skip /> > > > А в чём невнятность? Это же rpc, только сделанный велосипедом? > > > Как бы тебе сказать... Есть протоколы, которые представляют собой абстракцию. > Внося дополнительный уровень косвенности, он, "усложняя" разработку, > позволяют изолировать связанные таким протоколом части. В кавычках, ибо всё > усложнение уходит в отдельную библиотеку, и на том забывается. > > Примеры в разной степени удачных протоколов: dbus, xmlrpc, mime, rfc2822. Это > стандарты, совмещая которые, можно добиваться нужного эффекта. Например, я > использую rfc2822 + xmlrpc + mime + base64 > > xmlrpc: широкая поддержка в разных языках программирования > mime: инкапсуляция данных, информация о типах и кодировках > base64: надёжная передача бинарных данных > > Я не думаю, в какой кодировке работает бэкенд, корка или фронтенд. Это > неважно. Не парюсь, как передать картинку: Content-Type: image/png и т.п. Не > боюсь, что пробел или перевод строки что-то испортит. А данные могут > содержать в себе что угодно, вплоть до текстовых примеров протокола > альтератора или connexion. > > А есть протоколы, которые завязаны на конечные точки, которые связывают. > Например, таков протокол работы кэша модулей и ORB в connexion: я могу > его "засветить" наружу, но поймёт его только такое же ядро connexion, во всех > остальных случаях человеку придётся писать реализацию сначала питона, потом > connexion itself. > > Я не уверен, что мне удалось объяснить, но, кажется, аналогия вполне > прозрачная. > > > > > > А для переноса модулей между alterator и чем-нибудь ещё не помешают > > процедуры выяснения возможностей модуля. Умеет ли он работать > > синхронно/асинхронно, constraints, acl и т.п. > > > А существующие модули этого не умеют. Предложение ввести принудительную > типизацию данных и discover в протокол так и не вылилось ни во что. Как будто > летом ничего не было. Вместо этого модули лихорадочно плодились, используя > существующий протокол. > > Я не хочу писать второй альтератор со всеми его особенностями национальной > охоты. Так как в существующем виде протокол внешних бэкендов помрёт. Вместе с > бэкендами. А у меня нет стольких ресурсов: я не "mainstream", я не могу вот > так за здорово живёшь дропать большую работу. Возможно, если бы я занимался > только connexion, я бы и попробовал. Но у меня ещё и другие работы есть. > > Я не хочу создавать что-то совсем прекрасное, но несовместимое. Т.к. вся > работа, которая будет проделана в connexion на эту тему, в альтераторе не > пригодится -- ибо xmlrpc, mime, base64, dbus и тому подобное -- это, видимо, > слишком сложно для scheme. Всё равно всё сведётся к текстовому протоколу, > возможно, с элементами scheme. > > В итоге, я уже не пытаюсь внести какие-то идеи, я пытаюсь выяснить, куда > копать, чтобы не нужно было выкидывать на помойку наработанное. Мне это уже > пришлось сделать летом, когда я предлагал минимальные изменения в > существующий протокол, и даже написал баш-код для работы и шлюз connexion -- > но и кодировки, и бинарные данные на тот момент в альтераторе были не важны. > Ну, и rip какое-то количество дней работы. Которые можно было бы потратить на > улучшение самого connexion. > > <skip /> > > > -- > 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
