Главная | Настройки | NSFW
Тема:
Доски


[Ответить в тред] Ответить в тред

[Назад] [Обновить тред] [Вниз] [Каталог] [ Автообновление ] 14 / 1 / 10

xmpp клиент Anonymous No.1185
if-programmers-[...].png (85 KB, 500x303)
Подумываю ебашить вообще адовый суп, вариаций масса, но в целом схема примерно такая:
Главный процесс - авторизируется перед сервером, запускает все другие, в stdin им пишет соответсвующие станзы полученные от сервера (с префиксами длины, предварительно очищая от всякой возможной уязвимой хуйни, которая энивей недопустима в хмпп типа dtd, т.о. в этих програмулечках можно будет использовать любую хмл либу, а не ебаться со всякими sax), с их stdout читает станзы и шлёт серверу. Причём этот же главный процесс заботится о том чтобы каждая станза была доставлена, причём один раз, т.е. имплементирует ХЕР0198 и ХЕР0359.
Станзы "iq" идут к условному iqd, "message" к условному messaged, "presence" аналогично. Нонзы не имеет смысла выносить в отдельный процесс, я думаю, потому что насколько я знаю они всегда делают что-то непосредственно связанное с соединением.
iqd открывает UDS сервер. Подключившись к UDS серверу, клиент (т.е. любая другая программулечка), может послать один iq и получить ответ тут же, аналогично с префиксом длины, чтобы не ебаться с парсингом хмл, а просто скормить любой хмл либе всю станзу.
messaged открывает какой-нибудь простой локальный интерфейс для гуя или консосьного фронтенда, где у входящего сообщения например указывается тупо (расшифрованный) текст, дата, зашифровано ли, всякая такая хуйня - фронтенду подаётся на блюдечке, а гуй опять же шлёт текст, говорить зашифровать ли и если да то чем, ну и т.д. хуйня. Так же открывается UDS сервер, клиенты которого шлют интересующие namespaces, и получают все сообщения, их содержащие (через это будет работать условный pubsubd(ХЕР0330), который в свою очередь поднимет аналогичный сервер-два, которые предоставят простой интерфейс (им сможет пользоваться условный discod (ХЕР0030), который в свою очередь сделат подобное)).
Через pubsubd в т.ч. главный процесс сможет аннаунсить поддержку ХЕР0359.
Во всём этом блядском цирке например omemo будет организовать как-то так: подписываемся на pubsub сообщения о ключах, предоставляем UDS-сервер на который можно будет послать станзу <encrypted> хуйню и получить расшированный текст, этим сервером будет пользоваться messaged.
Отдельно будет жить хуйнюшка реализующая вот эту хуйню, например https://xmpp.org/extensions/inbox/omemo-media-sharing.html#aesgcm. Т.е. будет отдельный демон у которого фронтенд будет запрашивать файлы, а он уже будет решать - тупо curl'ом их надо качать, или по вот по этой хуйне.

Т.о. компоненты можно будет пилить разным людям, на разных языках, общаясь с простейшим апи. Я ебан? Где я проебался?
Anonymous No.1186
tl;dr: подводные хуячить клиент в виде кучи мелких програм одна из которых - гуй
Anonymous No.1521
>>1185 (OP)
Взгляни на jj, там одна программа и не раздуто.
Anonymous No.1575
Крч такая вещь: надо запускать "плагины" лениво, т.е. пока юзер не получил мессаджа омемо, то нехуй плагин омемо запускать, потому что способы шифрования ведь и другие есть - пгп и отр, ну и хули процессы просто так держать в памяти. Поэтому можно вообще не uds использовать, а тупо stdin/stdout, ну и iqd выносить отдельно нет смысла.
Вместо length-prefixes стоит заебенить просто либу чисто под хмл-потоки (без нетворкинга) с биндингами под разные языки.

Вообще огромный удар в псину разработке хмпп клиентов и свободных средств коммуникации в целом наносит существование ведра. Оно мало того что не поддерживает никакие человеческие тулкиты, так ещё и скриптовые языки через жопу только работают.

А сделано это чтобы простые аноны в свободное от РАБоты время точно ничего запилить не смогли. Разработка ПО должна быть привелегией властьимущих.

>>1521
Там вообще другое, не расширяемо нифига
Anonymous No.1650
>>1575
>не расширяемо нифига
Там пайп, хоть обрасширяйся. Или расширяешь внутри, нехуй плодить много мелких сущностей, ты не гугля.

>пгп и отр, ну и хули процессы просто так держать в памяти
Я думаю, пгп и отр — совсем малое, что будет держаться у тебя в памяти. Сравни жор какого-нибудь консольного клиента и десктопного/мобильного говнища.
Anonymous No.1651
>>1185 (OP)
>"message" к условному messaged
И тут ты такой захотел прикрутить к своему клиенту несколько хэндлеров на месседжи. Или ебануть бота, который вместе с месседжами полезет обрабатывать и другие станзы.
Anonymous No.1652
>>1185 (OP)
>Где я проебался?
Никто не полезет играть с кучей маленьких серверков, где у каждого свой api, проще выставить наружу ipc с одним большим api на все возможности клиента и как-нибудь возвращать назад ответы. Но никто это не полезет особо делать, потому что проще написать кучку кода на си, а потом привязать к хэндлерам на нужном тебе языке через ffi.
Anonymous No.1653
>>1652
> потому что проще написать кучку кода
>проще
>на си
Anonymous No.1695
>>1653
Да, проще, учитывая то, что иначе ты на нём же полезешь заниматься сериализаций в кастомный формат.
Anonymous No.1696
Если не сериализацией, то просто мультиплексом соединений.
Anonymous No.1698
>>1652
>Никто не полезет играть с кучей маленьких серверков, где у каждого свой api,
Unix так и живёт хули
Ну а вообще имхо можно сделать не апи а "фильтры" - допустим фильтр омемо будет обрабатывать все сообщения зашифрованные омемой, и просто в боди вставлять текст, а это далее будет передаваться отрисовщику гуя.
"Апишность" при этом можно будет свести до минимума - скажем, для отправки сообщения зашифрованного омемо с использованием такого фильтра достаточно будет добавить какой-нибудь "флаг" в станзу на этапе формирования её из юзер инпута, а там уже фильтр омемо её зашифрует нужными ключами и всей хуйнёй.
Anonymous No.1718
>>1698
>Unix так и живёт хули
Вот именно, что так не живёт. Unix -way в минимальном дизайне. Если можно сделать фильтра или генератор, делается именно так.
>допустим фильтр омемо
Не легче ли впилить фильтр омемы вообще как функцию, которая будет прозрачно обрабатывать входящие сообщения? Зачем процесс?
Anonymous No.1724
>>1718
Так затем, что функция она зависима от языка и таки устройства самого клиента, хотя это можно минимизировать . Поэтому у нас куча клиентов с разным количеством и качеством поддерживаемых ХЕРов - потому что для каждого клиента надо всё заново перепиливать.

Если так как я описываю, то можно запилить одну часть клиента на одном языке, другую на другом, потом ту первую перепилить на третий не изменяя ничего в другом, не ебясь с биндингами.
Можно к одной базе запилить несколько фронтендов - кому-то нрафки гтк, кому-то fltk лол, может кто-то обпердолится и под андроид запилит даже, приэтом понятно что часть кода занимающуюся преставлением надо перепиливать, но не надо каждый раз пилить заново самые основные херы.
Anonymous No.1728
>>1724
>Так затем, что функция она зависима от языка
А зачем тебе независимая от языка омема, если ты её запилишь в том же самом процессе в виде условно-прозрачного фильтра, через который будут проходить все станзы и, судя по твом же словам,
>достаточно будет добавить какой-нибудь "флаг"
>будет обрабатывать все сообщения зашифрованные омемой
? Вошло XML от сети — там же обработалось. Без лишних сущностей и пересериализации.

>Поэтому у нас куча клиентов с разным количеством и качеством поддерживаемых ХЕРов - потому что для каждого клиента надо всё заново перепиливать.
Так другие люди не будут пилить из кучки программ свои клиенты, максимум свой GUI прилепят, ведь им придётся начать серьёзно понимать за посылку сообщений у тебя в системе. И делать точно так же, как делаешь ты. Универсальной сериализации нет.
>Если так как я описываю, то можно запилить одну часть клиента на одном языке, другую на другом, потом ту первую перепилить на третий не изменяя ничего в другом, не ебясь с биндингами.
Тебе придётся вместо биндингов ебаться с сериализацией, разрабатывать свой формат для (мета)данных, к XMPP и даже к XML собственно относящихся боком. В особо радикальном случае пилить кросс-платформенную систему посылки сообщений, что вообще никто особо не сделал. Ну есть сообщения с акторами в эрланге, есть Binder в android, а ничего, что было бы везде, нет. Не забудь ещё, что засериализовать-развернуть данные уже тебе не захочется и ты полезешь писать свой IDL, собирающийся во все эти языки.
К слову, про Binder. Вроде как всё в том же Android работает через этот полумёртвый отросток беоси. IDL свой для жабки есть. На том же Android GUI (surfaceflinger, как кажется, намертво к этому binder и привинчен) массово пишут либо на той же жабке, либо рисуют на попенжле. Где масса широко гуёвых фреймворков на си и всякой скриптухе? Я бы хотел увидеть там тот же GTK, но он собирается с помощью какой-то магии и официально не поддерживается. Всего-то с сериализацией разобраться.

Ну и заново линкну свой пост >>1652. Написать один сервер проще десятков других. Обслуживать тоже проще. Это пусть гугли с амазонами ебошат по микросервису в секунду, у них больше денег и kloc/час несоизмеримо выше, чем у тебя.

>Можно к одной базе запилить несколько фронтендов
Это можно сделать и превратив клиент в огромную библиотеку с коллбеками, делая ffi там, где надо. И можно сделать один сервер, который будет общаться с нашим гуем по строго определённому протоколу, выкидывая в процессе весь XML по максимуму.

[Назад] [Обновить тред] [Вверх] [Каталог] [ Автообновление ]
14 / 1 / 10

[Ответить в тред] Ответить в тред

15000

Ответ в тред No.1185
Настройки
Избранное
Топ тредов