Стартовая страница

# ahamai to All @ Разбор idec №2 @ idec.talks 31/10/24 19:18

Во-первых, изначально у меня была ошибка, ?sf не прозрачна, её нельзя добавить вообще везде. Потому что есть php-ноды, и там должно быть &. Это, конечно, может задаватся в схеме, и это с точки зрения проектирования куда лучше, чем idec, но это не прозрачная замена, про php ноды я забыл.

Во-вторых, про схемы и проектирование было в прошлом сообщении в этой эхе. Если уже развивать схему, то зачем лезть в уже устоявшийся формат, нарушать его примитивность и топорность: примитивность реализации, примитивность самого формата. Зачем /u/e переюзывать?

Нормальным решением было бы завести свой неймспейс. Тем более, сеть это уже дважды проходила, сначала были /e и /m, но это было медленно и печально, запрос вещь дорогая, на самом деле даже дороже, чем лишний трафик. Потом была /z, потом была /u. И по урлу в конфиге указывалось, по какому протоколу работать. Точно так же можно было сделать и при развитии сети, какой-нибудь /r или /x, всё вынести в этот неймспейс. В случае чего (давайте представим этот дивный мир, где с /u/e ничего не сделали, он всё так же примитивен, как и был изначально) можно даже эмулировать старый интерфейс с неймспейсами /x/e и /x/m, если в старый клиент пропишут новую схему.

И уж если планируются расширения, совершенно точно не надо вешать какие-то костыли, чтобы вопрос "а как задать срез для каждой эхи" не имел ответа.

Про key/value. У босфора был такой интерфейс, /bb/key1/value1/key2/value2. Это было удобно сначала парсить в словарик, а потом с этим словариком работать, минимумом кода достигались красивые вещи, можно было делать разные запросы. Если что-то расширяешь, нужно сразу делать формат, который можно расширять, но который при этом фалбакается, если расширение не поддерживается. Зачем нагромождение ненужных сущностей, которые потом надо ещё прописывать? Когда можно сделать единый урл, единый словарик, а любой фильтр прописывать ровно одной строкой кода, и те системы, которые его не поддерживают, просто не будут по этому критерию фильтровать.

/u/m и /u/e это к тому, что это просто то, что осталось фундаментом, когда всё остальное было удалено для простоты. Тут кое-кто :) пытается переизобрести z/get, который был удалён из-за повышенной нагрузки на сервер, /u/e и /u/m это необходимый самодостаточный минимум, который вообще не должен меняться. А расширения - это то, что должно иметь возможность расширяться, а не хардкодиться в нескольких урлах, и что самое ужасное, при этом изменяя поведение базовых.

Я вообще не понял, к чему были эти изменения idec? Чтобы через 10 лет переизобрести их заново, потому что стандарт, предназначеный для расширения, оказывается не умеет расширяться? Это плохой дизайн. /u/e и /u/m при этом своей актуальности не утратили.



# revoltech to ahamai @ Re: Разбор idec №2 @ idec.talks 31/10/24 19:39

Уважаемый, я вот вроде тебя и понимаю, и не понимаю одновременно. Например, я пришёл сюда совсем недавно. Старую ii-документацию в этих ваших интернетах уже не сыскать, все старые сайты протухли. Откуда мне было знать про «эмпирическим путём найденный» лимит в 40 мессаг, про /z/get и прочие босфоры?

ahamai> И уж если планируются расширения, совершенно точно не надо вешать какие-то костыли, чтобы вопрос "а как задать срез для каждой эхи" не имел ответа.

Здесь согласен.

ahamai> Про key/value. У босфора был такой интерфейс, /bb/key1/value1/key2/value2. Это было удобно сначала парсить в словарик, а потом с этим словариком работать, минимумом кода достигались красивые вещи, можно было делать разные запросы. Если что-то расширяешь, нужно сразу делать формат, который можно расширять, но который при этом фалбакается, если расширение не поддерживается. Зачем нагромождение ненужных сущностей, которые потом надо ещё прописывать? Когда можно сделать единый урл, единый словарик, а любой фильтр прописывать ровно одной строкой кода, и те системы, которые его не поддерживают, просто не будут по этому критерию фильтровать.

И здесь согласен.

ahamai> и что самое ужасное, при этом изменяя поведение базовых.

А здесь не согласен. Здесь прав товарищ AL, который говорит, что поведение остаётся прежним, нужно только подкорректировать логику парсера. Ну, типа, старые /u/e никуда не деваются, нужно только посмотреть, есть ли двоеточие в последнем элементе и привет.

Другое дело, что логику парсера можно было бы упростить в разы, приняв концепцию железобетонной структуры key/value/key/value/..., но уже имеем то, что имеем.



# shaos to ahamai @ Re: Разбор idec №2 @ idec.talks 31/10/24 20:21

> Во-первых, изначально у меня была ошибка, ?sf не прозрачна, её нельзя добавить вообще везде. Потому что есть php-ноды, и там должно быть &.

Ну я ведь у себя поддержал list.txt?h=1 :)

Просто парсить надо будет вручную



# hugeping to ahamai @ Re: Разбор idec №2 @ idec.talks 01/11/24 09:45

Рома, не нервничай. У меня 3й день подряд мигрень, но я решил немного пояснить ситуацию, не влезая в детали. Как ты предложил. Но по существу! Мой ответ частично обращён к твоим другим сообщениям.

# Про дизайн и простоту ii

Я прекрасно понимаю твои доводы о простоте и сам практикую решения проблем "не в лоб". Это действительно круто, когда проблему можно "обойти" не решая её вообще. Plan9, кстати, отличный пример этого подхода. Я пришёл к этому не сразу, но когда так понял - сразу начал с радостью практиковать. На работе и в быту. И про питон + падения некорректных данных я тоже нормально отношусь. Мы пишем "чистые (сейчас не в терминах ФП)" функции при этом. А контролируемое падение питона (да ещё в рамках веб-фреймворка, например) это, обычно, не является проблемой безопасности.

Поэтому я лично пытался придумать что-то, что было бы так же просто как базовый ii, но всё-таки решало те проблемы, которые мне бы лично хотелось бы решить.

# Проблемы "базового" ii

Собственно это и есть краеугольный момент. Либо мы воспринимаем особенности ii проблемами либо нет. Я согласен, можно проявить аскетичность, смирение и "вложить" себя в базовый ii который предполагает:

- полный фетч;
- архивирование и "бегучесть" эх.

Но аскетика - дело добровольное. Если каким-то людям эти ограничения тесноваты - они вольны решать эти проблемы так, как они это способны делать. И даже, если они делают это по твоему мнению плохо и топорно, вправе ли ты их за это осуждать?

# Обсуждаемые изменения стандарта idec

Обсуждаемые изменения стандарта - в основном, реакция на взгляд со стороны о двусмысленных моментах. Андрей выкинул из текущего idec то, что посчитал лишним. Так что это упрощение. А то, что было неточно сформулировано - сформулировал. Речь вроде бы и не шла о "принципиально новом" стандарте. То-есть, мера хаоса была уменьшена, не революционно, но тем не менее. В этом и есть его ценность.

# Новый стандарт

Вот. А теперь самое интересное. Есть чистый стол. Есть ii. Есть упрощённый idec. И дальше развилка.

1) мне достаточно ii
2) мне достаточно idec
3) я могу сделать лучше

Ты можешь мне сказать где ты? Вроде бы ты на пп1, но при этом я вижу в твоих сообщения обсуждения решений тогоже sf, h которые вроде бы демонстрируют что то из пп3.

Ну так возьми и предложи, связанным текстом непротиворечивый стандарт, который по твоему мнению достаточен.

Я лично могу сформулировать несколько вариантов:

1) ii с полным фетчем но с надёжным механизмом проверки изменений в эхах узла (это то, что у тебя hash эх
2) ii с возможностью забирать n последних сообщений (это твой lim и/или sf)
3) ii с отдачей списка msgid в обратном порядке (моя идея)

Каждая из них мне не нравится по своим причинам:

1) Необходимостью хранить счетчики/хеши/что угодно - мой шкурный интерес. Я тоже иногда люблю экстремальную простоту. Приемлемо, но не прекрасно.

2) Невозможно "чётко" подобрать лимит такого захлёста. Сколько надо ставить чтобы и разброс порядка не влиял и интенсивность чата? 100? А если сисоп уехал в круиз а за пол года его отсутствия пришло 10000 пользователей? Нет, не надёжно.

3) Вроде всё четко технически (читаем и обрываем связь когда считаем нужным) но.. Есть элемент хака.

Текущий idec в терминах простоты мне тоже НЕ НРАВИТСЯ, но! Я НЕ МОГУ придумать лучше и так, чтобы были решены те недостатки, о которых я говорю. И вот слайсы, достаточно просты и их таки решают! И этот адаптивный фетч который ты называешь оверинженирингом, для меня это вынужденный шаг. Другого пути я просто не вижу. Если хочу избавиться от полного фетча и при этом иметь надёжность которая позволила бы мне бросить ноду и не следить за ней год (хотя бы и гипотетически)

В общем, давай конструктивно. Дружно. Корректно! (Мою ноду дети читают!) Предлагай решения если есть что предложить дополнительно или скажи, что тебя устраивает ii в чистом виде, но тогда и не нервничай. Дай нам двигаться своим путём.