[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-29 04:02:39
ahamai> Ну я показал как моя станция на это реагирует
Реакция твоего узла странная, но ни к каким последствиям не приводит.
[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-29 06:46:24
shaos> это как так? перечисляемые расширения были основной фишкой IDEC :(
Перечисляемые расширения вынуждают стандартизировать расширения. Придём к джабберу, где у каждого свой зоопарк и по факту в рамках сети рабоает только основа стандарта и пара расширений. Нафиг-нафиг.
А так, никто не мешает лепить любые расширения у себя. Просто не надо полагаться на то, что их будут поддерживать. Ситуация ровно та же, только более свободная.
[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-29 06:46:25
shaos> Ну у него эхи без цифр, значит уже наполовину IDEC ;)
Да не было в ii требования эх с циферками. Это была просто договорённость, а не стандарт. Эхи без циферек там прекрасно работали всю дорогу.
[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — tuple
2024-10-29 06:53:52
AL>> Словарик будет отдельным документом.
tuple> Лучше в самом документе словарик иметь.
Словарик не является частью стандарта.
[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-29 06:53:52
shaos>> это как так? перечисляемые расширения были основной фишкой IDEC :(
revoltech> Ну а теперь три из них являются частью стандарта, а остальные — нет. Вообще нет. Если я всё правильно понял.
Всё так. Расширения стандарта это путь вникуда. Лучше потихоньку принимать в стандарт полезняшки, если они будут действительно нужны.
[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-29 07:43:16
shaos> А как же делать кастомные расширения теперь?...
Я ж говорю, важна поддержка стандарта. Что там кто себе сбоку наворотил, это их личное дело и не должно влиять на всю сеть.
[>]
Re: Аутентификация поинтов через несекьюрное соединение
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-29 07:43:24
shaos> Вобщем мне никогда не нравилось, что в /u/point у вас пароль идёт прямым текстом (ну скажем https:// и POST ещё ок, но если речь идёт о ретроклиентах, которые умеют только http:// ?)
shaos> Для несекьюрных каналов можно попробовать альтернативный способ аутентификации пользователя скажем через подпись HMAC-RIPEMD-160-96. Алгоритм HMAC это hash-based message authentication code (код аутентификации сообщения на основе хеша), который использует один секретный ключ, известный обеим сторонам, и над каким-то стандартным хешом - в данном случае это RIPEMD-160 (алгоритм хеширования с наименьшей длиной хеша, который ещё не сломали), причём этот алгоритм был представлен ещё в 1992 году (т.е. ему уже 32 года!) - он в частности используется в биткоине (вместе с SHA-256). Ну и для укорачивания такой подписи берутся первые 96 бит (12 байт). Это всё стандартизовано на уровне RFC:
shaos> RFC2104 (February 1997) - HMAC: Keyed-Hashing for Message Authentication
shaos> https://datatracker.ietf.org/doc/html/rfc2104
shaos> RFC2286 (February 1998) - Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128
shaos> https://datatracker.ietf.org/doc/html/rfc2286
shaos> RFC2857 (June 2000) - The Use of HMAC-RIPEMD-160-96 within ESP and AH
shaos> https://datatracker.ietf.org/doc/html/rfc2857
shaos> Конечно было бы лучше использовать SHA-256, но RIPEMD-160 проще в вычислительном плане, а нам надо будет его считать на слабых платформах. Вобщем суть такая - секретный ключ (это может быть строка текста длиной до 20 символов) загружается на узел через секьюрное соединение (https:// или скажем через емейл сисопу) один раз. Далее когда пользователь хочет отправить сообщение на узел (в описанном выше формате) по несекьюрному каналу, то его клиент считает по телу сообщения и секретному ключу подпись HMAC-RIPEMD-160-96 и посылает 12-байтовый результат как PAUTH (можно наверное в base64url его завернуть), а сервер при получении будет считать по полученному телу сообщения свой вариант HMAC-RIPEMD-160-96 и будет сравнивать с присланной подписью - если результат совпадёт, то отправитель считается аутентифицирован (плюс будет проверена целостность самого сообщения). До кучи в урл можно добавить кодировку, на тот случай если софт поинта не поддерживает UTF8:
shaos> URL/u/point2/koi7/B64AUTH/B64STRING
shaos> для больших сообщений можно задействовать метод POST:
shaos> URL/u/point2/koi7/B64AUTH
shaos> TEXT
shaos> причём тело сообщения в данном случае можно заслать прямым текстом без кодировки (Content-Type: plain/text)
shaos> Обсуждаем? :)
Да чего тут обсуждать? Нормальное расширение -- делай.
[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-29 07:43:31
shaos> Ну т.е. теперь исключается сама возможность торкнуться на узел специальным образом, чтобы узнать одним списком а какие собственно расширения он поддерживает...
Почему? Хочешь сказать, что со старым стандартом исключалась сама возможность получить у тебя /list.txt с хешиками?
[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-29 07:43:31
shaos> https://github.com/idec-net/new-docs/blob/master/iibonds.md
shaos> Минусы оригинального ii:
shaos> - Название эхоконференций от 3 до 60 символов, эха обязана заканчиваться на постфикс (точка и число).
shaos> - Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
shaos> - Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую
Имеет смысл читать ii, а не кривую документацию по IDEC.
shaos> Наши улучшения
shaos> - Название эх от 3 до 120 символов, из них обязательный символ - только точка (без цифровых постфиксов)
shaos> - Небольшие расширения, которые помогают экономить трафик, защищают от переполнения эх и делают ещё пару полезных вещей.
shaos> ВСЁ!
Да.
[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — tuple
2024-10-29 10:14:36
AL>> Имеет смысл читать ii, а не кривую документацию по IDEC.
tuple> Между прочим, а где её найти? На лоре ссылки на умерший 51.ru, который тот самый с девочками, судя по веб-архиву. В интернете - IDEC.
Не знаю. Мы уже давно отдельно.
[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-29 17:58:50
shaos> Ну я добавил их в /x/features и типа сразу видно что оно у меня есть ;)
Ну так и оставь их в /x/features. Никто ж не мешает ;)
[>]
Re: Аутентификация поинтов через несекьюрное соединение
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-29 17:58:50
shaos>> Кстати - если этот номер перехватить, то его ведь можно тут же зареюзать пока время не прощло?
revoltech> Нельзя. Ну как минимум сервер должен такие попытки пресекать и заставлять пользователя ждать следующее 30-секундное окно. Это в случае TOTP.
revoltech> Легитимный пользователь в пределах 30 секунд 2 сообщения не отправит. А если надо, пусть отправляет через /u/push.
Ты шутишь сейчас? Лигитимный пользователь может подряд сколько угодно сообщений подряд отправлять. А /u/push вообще не для пользователей, а для других узлов сети. В том же цезии я не отправляю по одному сообщению, а отвечаю сразу на всё, что нового прилетело, а потом они пачкой по одному улетают. Зачем ломать клиенты?
Или ты предполагаешь, что клиент, отправив сообщение, будет ждать 30 секунд перед отправкой следующего? Нафиг такой клиент нужен тогда?
[>]
Re: Аутентификация поинтов через несекьюрное соединение
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-30 06:50:13
shaos> А у пуша какой пароль - пользовательский или особый сисоповский? Надо код ii-php поглядеть…
По хорошему особый сисоповский должен быть. Потому что пуш для межузлового взаимодействия. Поини в принципе не может слать пуш, так как в пуше уже зарегистрированные сообщения летят, а не пользовательские.
[>]
Re: Стандарт
idec.talks
Andrew Lobanov(tavern,1) — hugeping
2024-10-30 09:28:24
AL>> Внёс правки по итогам замечаний и предложений. URL тот же: http://s.spline-online.ru/idec.html
AL>> PS: Перед окончательной публикацией дождусь реакции hugeping.
hugeping> Вроде бы всё нормально! У меня был вопрос про push как часть стандарта. Он нужен только когда нода не имеет реального IP адреса? С другой стороны, как тогда поинта забирают с неё сообщения? Какой-то изолированный сегмент сети?
Ну по сути да. Если вдруг есть узел в сети с ограниченным доступом в интернет, например. Поинты у него локальные, а наружу только пуши до аплинка. Ситуация гипотетическая и с каждым годом всё менее вероятная, хотя, с другой стороны, с этими всеми взаимными блокировками может оказаться всякое :)
hugeping> С другой стороны, всё равно эта часть возможна только за счёт предварительной договорённости нод (выдача пароля), так что думаю - наличие push в стандарте не приговор, а лишь означает, что ПРИ НЕОБХОДИМОСТИ этот механизм может использоваться. То-есть, для работы в обычном режиме нам по прежнему push не нужен...
Ну да. В обычном режиме push не нужен.
hugeping> Про фичи - по идее они полезны были бы для определения, например, поддерживает ли нода слайсы. Но на практике, tgistation их не поддерживает, но в фичах есть u/e. В общем, я не жалею, что их больше нет. Стало проще. Меньше комбинаций. Ориентироваться можно на фактически получаемые данные.
Ну вот не будет фич. Будет просто стандарт. Остальное вообще не важно вне рамок каких-то локальных приколов.
hugeping> P.S. Я бы оставил ещё повисеть драфт, мы же никуда не спешим? Вдруг кто-то что-то вспомнит. :)
Ну спешить некуда.
[>]
Re: Срез
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-30 09:28:24
ahamai>> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
revoltech> Кстати, да, присоединяюсь к вопросу. Как в одном запросе слайсить сразу несколько эх с разными смещениями и лимитами? Например, мы запрашиваем содержимое трёх эх и выяснили, что из первой надо забрать только 3 последних сообщения, из второй — 10, а из третей — 50. И что, здесь три отдельных запроса городить придётся?
Бери один по максимальному смещению.
[>]
Re: Срез
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-30 09:28:24
hugeping>> ahamai> А какой вообще формат срезов: /u/m/эха/срез/эха/срез или как?
hugeping>>
hugeping>> Например: https://club.hugeping.ru/u/e/idec.talks/-1:1
revoltech> Вопрос в том, что делать, когда в запросе НЕСКОЛЬКО эх. Можно ли указать диапазоны отдельно для каждой?
Нельзя, так как незачем.
[>]
Re: Срез
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-30 13:32:39
ahamai> Ничё не понял. Если щас задать несколько эх и дать срез, он со всех по n сообщений запросит или только с последнего
Со всех, если я правильно понял типавопрос.
[>]
Re: Срез
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-30 13:32:45
ahamai> Тогда не понял, почему стандарт такой, если в каждой эхе разное количество новых сообщений. :) Ладно, поняли-разобрались. Стандарт читал но как-то не задумывался об этом, задумался только сегодня в тронвае :)
Потому что не надо байто**ить. Сильно помогает в подавляющем числе случаев.
ahamai> 2shaos - фетчеры обновил
[>]
Re: Срез
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-30 13:32:46
ahamai> у меня sf работает так: запрос вида /u/e/эха1/эха2/эха3?sf=хэш1/хэш2/хэш3, и она ищет указанные хэши в эхах, если находит, начинает выдачу эх с них. сначала не вклчая сами хэшN, но несколько дней назад я сделал, чтобы включали, на всякий случай, 21 байта не жалко, зато можно убедиться, какой именно хэш
А если хеш в блеклисте или вообще удалён? Ну и сложно это в реализации и не особо незачем.
[>]
Re: Аутентификация поинтов через несекьюрное соединение
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-30 13:32:46
>> По хорошему особый сисоповский должен быть. Потому что пуш для межузлового взаимодействия. Поини в принципе не может слать пуш, так как в пуше уже зарегистрированные сообщения летят, а не пользовательские.
shaos> Может тогда как-то почётче это в стандарте про push проговорить?
Хорошо. Принимается.
[>]
Re: игры в эхах
idec.talks
Andrew Lobanov(tavern,1) — tuple
2024-10-30 15:25:01
tuple> А ещё можно передавать сохранения игр, проходя их по очереди. Те же дварфы (dwarf fortress). Много чего можно сочинить.
У нас нельзя передавать файлы в общем случае. Да и бородачи нынче не те. Я так и не освоил новый интерфейс.
[>]
Re: Срез
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 05:21:38
ahamai> Хэш в блеклисте это вообще ничего не меняет, нужны же "сообщения от", если в файле эхи сообщение есть, то от него и пойдёт. Если хэша нет, то отдастся вся эха. По сравнению с текущим случаем, преимуществ два - хэш гораздо более надёжный источник, чем количество сообщений, и не сработает только в одном случае: если конкретная нода инъектировала в эху сообщения сверху - но на это нужно иметь настолько серьёзные основания, что это повод говорить об этом в сисопской эхе.
Какие-то количества сообщений придумал. Нет их уже, считай. Легаси, который в скором времени выставим на мороз.
> Ну и второе - точно отдадутся только самые новые сообщения, одним запросом (я думал, реализация срезов вообще не так работает, в текущем виде она вообще какая-то непонятная, почему на все эхи один лимит, если сообщений в базе мало)
Как количество сообщений влияет на работу срезов? Out of range невозможен.
ahamai> не использовалось это никогда потому что я не вижу смысла экономить и так копеечный трафик. но на такой случай реализация в моей станции была
Если не видишь смысла экономить трафик, то тогда непонятно что тебе не нравится в том, что срез один на запрос, а не для каждой эхи отдельно. Я думал, ты байтики экономишь и не хочешь получать в индексе сообщения, которые у тебя уже есть в базе.
[>]
Re: Срез
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 05:21:39
ahamai> Понятия не имею, что это слово означает, но вопросы имеются - раньше я вообще никогда не задумывался, как работают слайсы.
ahamai> Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи.
Читай документацию внимательнее. Там не только эхи перечисляются.
ahamai> Почему не использовать что-то типа ?s=-100:100 или любой другой способ?
Мы и используем один из любых других способов.
ahamai> Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения.
Почему у тебя фетчер считает имя эхи хэшем сообщения? Это явно что-то не так в ii 0.3. Зачем с аплинком на ii использовать то, что ii не умеет?
ahamai> Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?
Никакой неоднозначности нет. Не может быть двоеточия в имени эхи. Если софт такое допускает, значит софт надо исправлять.
ahamai> Ладно, раз уж решили изнасиловать формат /u/e, почему не использовать /u/e/эха/срез/эха/срез.
Зачем?
ahamai> Это же для экономии трафика всё затевалось? А какая экономия, если у тебя может быть куча эх, и ради одной роботной, где всегда куча сообщений, тянется куча ненужных?
1. Ты тоже в максималисты подался? Затем, что лишних несколько сотен байт на фоне нескольких сотен килобайт это экономия трафика.
2. Ненужные сообщения не тянутся. Только новые. u/e, если ты забыл, даёт только индекс, но не сообщения.
ahamai> А если поодиночке - то это лишние запросы, на медленном и нестабильном интернете каждый запрос это всегда больно, и он может даже не состояться
И этот человек защищал кучу маленьких бандлов вместо всего в одном запросе.
ahamai> Формат /u/e был придуман ровно для того, что дёргать /e на каждую эху было медленно и неэффективно.
Однопоточный фетчер на срезах на перле, который тянет индекс по одной эхе и использует бандлы по 40 сообщений, утягивает клуб за 3 минуты. На медленном канале.
Он же, но с парой десятков сообщений новых сообщений работает 3-5 секунд.
Без новых сообщений он отрабатывает за 3-4 секунды.
ВНИМАНИЕ! Вопрос: куда ты так спешишь, что у тебя каждая секунда на счету?
[>]
Re: игры в эхах
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 05:21:39
>> Можно передавать уровни сокобана в plaintext-формате (.sok).
ahamai> это всё не так весело, тут играешь в одиночку. а я именно про игры всей компанией и совместную вовлечённость
Многие НРИ годятся для такого занятия. Всей гурьбой, увлекательно, разнообразно.
[>]
Re: Срез
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 05:21:39
ahamai> - если сообщений в базе мало
ahamai> + если новых сообщений в эхах разное количество, непонятно почему просто не запрашивать с каждой нужное (ну, или, с гарантией +1, +5 сообщений, это небольшой оверхед, по сравнению со случаем когда опращиваются одним запросом эхи с 1 и 110 сообщениями)
ahamai> 111
ahamai> Вообще, связка h и sf реально сокращает количество запросов и реально экономит трафик. Если это кому-то важно.
Оверхед меньше килобайта в подавляющем большинстве случаев. Это даже на 9600 бод можно не считать оверхедом. При этом ты предлагаешь более сложный и неработающий в части случаев вариант.
[>]
Re: игры в эхах
idec.talks
Andrew Lobanov(tavern,1) — tuple
2024-10-31 05:21:39
tuple> Ещё есть вариант найти мастера, сыграть в D&D.
В общем случае неудобно. Карту надо и токены.
tuple> P.S. Чур я бард-человек.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 05:21:39
Я честно пытался с тобой обсуждать, но ты, похоже, наркоман. Ты видишь то, чего нет.
За сим считаю, что обсуждение стандарта с тобой можно завершать. Какие счётчики? Какое скачивание лишних сообщений? Если ты не читал то, что я сюда приносил как черновик, то открой хотя бы исходники своего ii-0.3. Почитай на досуге. Сразу увидишь где ты неправ в своих претензиях. Ну а если не увидишь, то обсуждать с тобой дизайн, стандарт и реализацию тем более нет смысла.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 05:21:40
shaos> Не надо драматизировать :)
shaos> Индексы тоже пару строк кода добавляют (ну может чуть больше)
shaos> Для разнообразия можно множественные "слайсы" тоже сделать, типа
shaos> /u/e/echo.1/echo.2/-1:1/echo.3/-100:100/echo.4
shaos> будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)
И это ломает поддержку стандарта.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 05:21:40
ahamai> кто будет переписывать цезий или фетчеры под замену стандартов? стандарты уже такие, какие получились. у меня вопрос - чому так?
Из стандарта выкидывается то, что по факту никому не нужно. Стандарты полностью совместимы с ii. Так что не понимаю твоего бухчения. Ты можешь взять хоть свой горячо любимый ii-0.3 и работать в сети полноценно.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 05:21:40
>> кто будет переписывать цезий или фетчеры под замену стандартов?
shaos> никто - сервер может поддерживать и ванильный ii без индексов, и старый IDEC где индексы в конце, и новый многоиндексный вариант - ничто ничему не противоречит!
Ну просто всё несовместимое снимается с фетча. Зачем нам поломанные узлы?
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 05:21:40
shaos> Блин как эти ==== в этом ii-php работают?
Это знает только автор. И то вряд ли вспомнит.
shaos> Ненавижу регулярные выражения...
Что может быть проще? Грамматики? Конечные автоматы?
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 05:36:00
ahamai> Можно хоть xml регекспами парсить. Я спрашиваю зачем добавлять в список эх что то ещё, делать проверки которые можно было не делать, терять в прозрачности, если всё это можно было сделать кучей способов, каждый из которых лучше. Какую проблему решили добавив неэховую инфу в /u/e?
Проблему длинных индексов. Всё максимально прозрачно и понятно. Использование разных по смыслу значений в роутерах это нормальная практика. Посмотри хоть на ii. У тебя /u/e -- часть пути, которая определяет функционал. А параметры у неё что? Тоже часть пути. Зачем ты сделал эту неоднозначность?
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 05:36:00
ahamai>> Складывается впечатление, что idec это пример плохого проектирования.
revoltech> На это я пытался намекнуть чуть ли не с первого дня появления здесь.
Но ты всё ещё здесь. В интернете кто-т неправ? Или что?
ahamai>> MSGID? по логике вроде бы да.
revoltech> Нет, в msgid тоже двоеточий быть не может. И длина должна быть 20 символов.
ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.
revoltech> Но в целом согласен, текущий формат слайсов какой-то недоработанный. Не то чтобы его сложно реализовать, но задачи экономить трафик при запросе большого количества эх он действительно не решает.
Ну да. Вместо выкачивания сотен килобайт мы выкачиваем сотни байт. Никакой экономии!
В общем, обсуждение не имеет смысла. По делу все высказались, рассуждения не по делу не имеют смысла.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:20
AL>> И это ломает поддержку стандарта.
revoltech> Ладно. Ломает, так ломает, будем контекстозависимые парсеры городить. А что насчёт /u/mc?
Ненужная вещь.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 07:52:20
>> Это знает только автор. И то вряд ли вспомнит.
Да там всё в коде - читай нехочу, но только без поллитры в этих регекспах не разрбраться (мне):
if (preg_match("/^====$/", $string[$i])) {
if (!$pre_flag) {
$pre_flag = true;
$string[$i] = preg_replace("/====/", "<pre>====", $string[$i]);
} else {
$pre_flag = false;
$string[$i] = preg_replace("/====/", "====</pre>", $string[$i]);
}
}
А что тут разбираться? Может, кто-то пихает пробелы после ====? Ну так надо просто им напихать в панамку за это.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 07:52:20
>> Что может быть проще? Грамматики? Конечные автоматы?
shaos> Мне проще на сях - перебираем строку посимвольно и делаём чо хотим...
Как только начинаем писать что-то сложнее поиска подстроки, код на Си превращается в чан доширака. Регулярки надо осилить один раз и потом кратко и лаконично описывать желаемое.
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:21
revoltech> Предлагаю ввести общий слайсинг вида «ключ-значение», в котором вместо диапазона можно писать all или же msgid (в таком случае берётся содержимое эхо от него):
revoltech> /u/e/echo.1/all/echo.2/some_msgid_blablabla/echo.3/-10:10
Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — shaos
2024-10-31 07:52:21
shaos> ну IDEC клиентов и серверов наклепали за 10 лет некоторое количество, поэтому и /u/e/echo.1/echo.2/echo.3 и /u/e/echo.1/echo.2/echo.3/-10:10 должны продолжать работать, а я предлагаю раширение, которое исправит последнюю претензию, что слайс распространяется на каждую эху из списка - будет возможность задавать разные слайсы на разные наборы эх в пределах одного запроса - чем плохо то? ;)
Тем, что не решает никаких проблем :)
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:21
shaos>> ну разве что если /x/e/...
revoltech> Да пофигу, раз упростить алгоритмически всё равно ничего не получится, пусть будет так, как есть. Меня больше про /u/mc вопрос интересует.
Не вижу в нём смысла.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 07:52:21
ahamai> Кстати, если в срезе будет точка, то старый софт будет считать это не как неккорректный msgid, а как пустую эху и и игнорировать её
Ты хочешь в срезе получить нецелое количество сообщений? Зачем тебе точка в срезе? Типа, -12.5:12.5?
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 07:52:21
shaos>> насколько длинный урл можно скормить вебсерверу это настройка вебсервера - сама нода может про это и не знать
revoltech> Но её админ должен об этом знать. И выставить в урлу /u/mc. Иначе при перефетче придётся брутфорсить на стороне клиента: ага, 10000 айдишников — отлуп, 1000 айдишников — отлуп, 500 — отлуп, 389 — норм... Запишем, что в этой станции 389.
А зачем?
[>]
Re: Топ 10 ваших команд
linux.14
Andrew Lobanov(tavern,1) — tuple
2024-10-31 10:43:25
tuple> А покажите топ 10 ваших команд из сохранённой истории (history) и предоставьте объяснения, почему они в этом топе.
tuple> ====
tuple> $ history | awk '{print $2}' | sort | uniq -c | sort -rn | head -n 10
tuple> ====
$ history | awk '{print $2}' | sort | uniq -c | sort -rn | head -n 10
103 sudo
69 go
67 tar
32 cat
27 find
22 du
21 ls
20 cd
18 ./sb_pilot
16 git
Собственно, тут становится понятно, что я слишком увлекаюсь sudo. Но это лишь потому, что сбер свой модуль работы с пинпадами писал жопой (как и всё, с чем я у них сталкивался по работе) и он только под рутом адекватно работает.
[>]
Re: Топ 10 ваших команд
linux.14
Andrew Lobanov(tavern,1) — hugeping
2024-10-31 10:43:25
hugeping> P.S. забавно, что в mc я не использую F1-F10 (вместо этого - esc-<цифра>) Я не помню как это произошло, но других любителей mc это всегда очень удивляет!
А что, так можно было?!
Теперь буду использовать так. Это же гораздо удобнее.
[>]
Re: Разбор idec
idec.talks
Andrew Lobanov(tavern,1) — ahamai
2024-10-31 10:43:05
>> ahamai просто не помнит свой же стандарт. Надеюсь, у него всё хорошо.
ahamai> В бандле только эхи и msgid.
Ещё пустая строка.
ahamai> Эхи с точками, всё осталное msgid. Если там что то ещё, падай а не игнорируй
Откуда оно там возьмётся?
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — revoltech
2024-10-31 10:43:17
AL>> Зачем? Усложнение ради усложнения? Так IDEC не про это, а про дубовую простоту.
revoltech> Это как раз и было бы про дубовую простоту парсинга. Ключ-значение. Всё однозначно.
Тут слайс, тут волшебное слово, тут хэш. Сиди, разбирай.
[>]
Re: Дополнения к стандарту
idec.talks
Andrew Lobanov(tavern,1) — hugeping
2024-10-31 10:43:24
hugeping> Я тут несколько дней сдерживаюсь. К тому же, довольно сильно приболел.
hugeping> Но сдерживаться мне всё тяжелее конечно...
hugeping> Понимаю, что меня не воспримут, всё-таки напишу.
hugeping> Подумайте, что за задачи вы решаете?
[skipped]
Подписываюсь под каждым словом.