= Сообщение: 2027 из 2457 =================================== RU.FTN.DEVELOP =
От : Nil A 2:5015/46 06 Jan 22 05:34:24
Кому : Sergey Anohin 06 Jan 22 05:34:24
Тема : Фидодевелопмент - давайте обсуждать тут, а не по .pr и .nextgen
FGHI : area://RU.FTN.DEVELOP?msgid=2:5015/46+61d6719a
На : area://RU.FTN.DEVELOP?msgid=2:5034/10.1+d255b9e1
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:5034/10.1+d26296e4
Ответ: area://RU.FTN.DEVELOP?msgid=2:5020/545+61d7ef72
==============================================================================
Hello, Sergey!
Wednesday January 05 2022 12:01, from Sergey Anohin -> Nil A:
SA> Из-за завышенного чсв люди изобретают велосипеды, один кривее другого,
SA> так как копаться в чужом коде зашкварь, а сделать с нуля путевую вещь
SA> слишком трудозатратно.
100% с тобой тут согласен.
Я понимаю, что одному с нуля труднозатратно, если только это не какая-то короткая утилитка.
Я с удовольствием бы коллаборировался с кем-нибудь, но, пока вот никак не случается.
Расскажу как ковырялся в husky. Оригинальных авторов, как я понимаю, в сети уже нет, но есть несколько мейнтейнеров. Миша Дукельский недавно там вычистил захардкоженне "константы", типа return 7; if (result == 9), хотя там спагетти код ещё немного присутствует.
Вообще я не очень люблю ковырять эти старые Сишные проекты, слишком низкоуровнево приходится писать. Я так как бы не против драйверочек там на Си, но если в юзерспейсе надо тупо много работать с текстовыми строчками (то, что делате хаски), то на Си это не так изящно.
Наверное есть какой-то новый девелопмент, например, научить SMAPI ходить в SQL (правда пока не пойму какие плюсы от этого). Но опять же, хаски это сплошная дрочня с указателями/индексами по char* и ручные списки с ними (вместо человеческих стрингов, вектор/лист стрингов и алогоритмов работы с ними), толпы циклов с большим количеством состояний (вместо понятных стандартных алгоритмов типа свёртки, фильтров и пр).
Или вот binkd, например. Не знаю, были ли уже в то время библиотеки libevent, libev, libuv (это уже новее), но куча кода для кросс-платформенной работы с сокетами могла бы уйти. А, ну OS2 и Amiga поддержки не будет, да и с djgpp может не собраться, вот зачем самим пришлось писать. Ещё там какие-то предупреждения по поводу тредов, надо пользоваться форками, явно какие-то баги с этим связанные, пусть библиотека этим заботится.
Можно, например, научить binkd читать fidoconfig, ведь там линки с паролями уже есть, только добавить секцию бинк-специфичных опций. А так что ещё допиливать? Добавить по-взрослому рейт-лимиты, чтобы противостоять натиску DDoS?
А вот все современные аффтары, что-то какие-то они мне мало симпатичные, к сожалению.
Ещё удивляюсь, что не найдётся ни одного фронтендщика, который скажет: "я так сильно хочу, но я не понимаю в бакендах" - так мы поможем с бакендами то! А то сами мы, технари, всё как-то меньше с гуями связаны.
SA> Сам же писал что использовать напрямую фидобазы не получится, т.к. все
SA> равно придется использовать вторую базу для хранения служебной инфы...
Я щитаю, что JAM/Squish базы первичны, и в них уже есть вся информация. Можно создать пул-IO-воркеров для работы с диском, к нему уровень кэша, и на одном сервере можно выдержать хайлоад, сильно лучше, чем ходить в SQL.
Сбоку можно хранить кэши просто, считай разные индексы, чтобы быстро отвечать на отдельные типы запросов. Кеши и индексы всегда можно выкинуть и перестроить, база остаётся как есть, в JAM/Squish.
Даже для ластридеров для разных пользователей есть место в стандартных базах. Только вот пометка на уровне каждого сообщения, прочитано оно или нет - это в базах без привязки к userid.
Нетмейл на поентоф можно также хранить в JAM/Squish, и хуком в HPT научить туда натоссивать.
SA> Ну и там есть противники похорон офлайн режима наверно
Оффлайн можно свести к кешированию впрок на стороне читалки. Под iOS NNTP читалка Newstap - она соединяется и вытаскивает вообще все статьи и отключается. В этом смысле теряется сквозная интеграция с ластридерами правда.
Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
|
