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

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 при этом своей актуальности не утратили.


idec.talks Ответы Цепочка Ответить