[Devel-conf] TODO на alterator
Stanislav Ievlev
=?iso-8859-1?q?stanislav=2Eievlev_=CE=C1_gmail=2Ecom?=
Вт Мар 25 11:10:00 MSK 2008
Петя, когда же ты наконец поймёшь, что alterator находится в других
условиях нежели connexion. А то тебя послушаешь: сидит тут злобный
Стас, как собака на сене и ничего не хочет и не даёт делать. Вот
глядите как я клёво придумал и как тут у них всё криво. Я хочу их
спасти, а они упорно отказываются.
Протокол бакендов был сделан очень и очень давно, тогда и мысли были
другими и задачи стояли иные.
Модули писались и будут писаться постоянно - ибо встают разные задачи.
Я не могу мгновенно взять и внедрить типизацию и что-нибудь там ещё.
Или одним махом взять и сделать backend4 с другим более классным
протоколом и послать все модули куда подальше.
Иногда чтобы сделать одну простую вещь надо предварительно подготовить
с десяток других мест, подтянуть в Сизифе с десяток модулей.
Как только где-то возникает готовность к изменениям - я сразу начинаю
это обсуждать. А сейчас и всё TODO стало полностью публичным. Вот
лучше бы почитал его и подумал бы какое выбрать направление движения,
какие нюансы надо ещё прояснить, чтобы оба проекта взаимно обогащали
друг друга, а не разбегались.
Понимаешь: мне надо знать не только какая клёвая штука xmlrpc или
base64, а ещё как к этому прийти.
24.03.08, Peter V. Saveliev<peet на altlinux.org> написал(а):
> В сообщении от 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
> devel-conf на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-conf
Подробная информация о списке рассылки devel-conf