[Devel-conf] TODO на alterator

[Stanislav Ievlev]

Петя, когда же ты наконец поймёшь, что 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