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

ahamai to hugeping @ Re: Дополнения к стандарту @ idec.talks 31/10/24 18:59

> Например, в данном случае, в один запрос запиханы разные лимиты слайсов для разных эх. Зачем?

Так это была изначальная идея - для экономии трафика. я всегда думал, что оно именно так и сделано, там 100 rss сообщений за час их и забрали, там 1 за неделю. а так это какая-то полумера, ни туда ни сюда.

> Потом, Рома трясёт своим ?sf=hash - как замену слайсов.

Приехали. Я не использую ?sf. Я не собираюсь использовать ?sf. Оно создано ровно для одного случая, работы в условиях медленного интернета. Для чего, как заявлялось, и делался idec. И, в отличие от idec, он делает ровно то, что от него просят, даёт одним запросом ровно то, что нужно, минимальный объём сообщений.

> На самом деле этот sf=hash при своей красоте, всё-таки, хуже слайсов. Во первых, даже с хешем надо делать запрос внахлёст с запасом (не забываем про то, что порядок сообщений на ноде может не совпадать с нашим)

Не надо так делать. В 99% случаев запрос вернёт ровно то, что от него хотят. В остальных случаях, скорее всего, поможет только полный фетч.

> и нам все равно придётся самим на своей станции находить n сообщение от конца в эхе и брать затем его хеш чтобы сформировать запрос. Те же слайсы, вид сбоку.

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

> Ну и во-вторых, sf решает одну конкретную задачу, а слайсы - универсальны. Слайсы делают возможным адаптивный фетч и онлайн просмотр.

То, что называется слайсы, у меня называется lim. Сделано одной строчкой кода. Совместимо вообще со всем, не ломает /u/e/, и даже клиенты, которые понятия не имеют о lim, могут им пользоваться.

Адаптивный фетчинг это оверинжиниринг, программирование ради программирования, он вообще не даёт гарантий, в станциях где нет формальных эх а сортировка идёт по timestamp, могут быть вкинуты старые сообщения и такой фетчинг их не увидит. В нормальных условиях я вообще не вижу проблем гонять полные эхи, ибо только они дают полную гарантию. Для экономии трафка можно использовать ?h, его использование в гейтовании с shaos сократило дневной трафик с 12 мб до 2.

> В общем, попытки решить какие-то несуществующие проблемы и навязать какие-то свои оценки. Чего я боялся, то и происходит. Лебедь рак и щука.

Проблема была в проектировании. Некорректном дизайне. В сломе того, что просто работало и было простым, как три копейки, ради решения несуществующих проблем и каких-то непонятных смен стандарта, которые ничего не дают, кроме экономии трафика, которой тоже нет, потому что у тебя либо постоянные новые запросы, новые коннекции, новые строчки в логе сервера и так далее, да там tcp фреймы больше сожрут чем трафика сэкономится :)

Забавно, я посмотрел архив старых эх - я постоянно из протокола что-то выкидывал, пока не остались /e /m /u/e /u/m, и всё это не достигло предельной простоты. А щас только что-то добавляют. Да сколько угодно. Но не надо лезть в /u/e. Это база из баз, фейлбек из фейлбеков, он должен быть простым, примитивным, кодиться за три строчки кода на любом языке и быть единой везде. Расширяйте как хотите, но расширяйте отдельные методы, без x/feaures и прочего фиг пойми зачем, может нода работать по новому - запрашиваем, не может - фэлбэчимся на старое. Или это можно прописать в конфиге, например как здесь:

****
ii.about.2014
1396407760
51t
lenina,1
51t
Re: есть идея вообще всё нафиг переделать

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

1. сделать рядом с /z/ ещё одну (а не 8, как планировалось) реализацию, /u/ - без zlib и для обычного base64. /u/ должны будут поддерживать все серверы и все клиенты, всегда. /z/ - пока будет вотчина python, а там посмотрим.

2. так и сделать - вместо хттп://51t.ru/ писать хттп://51t.ru/z/. или хттп://51t.ru/u/. или даже хттп://мойсайт.ру/ii.php?q=/u/, по нему и определять, если на /z/ заканчивается - значит схема python, если на /u/ - значит плоская схема. для получения - всегда останутся /m/ и /e/

3. пока будет опциональным. пусть внедряется. :)
****

А стандарт обмена между станциями это стандарт обмена между станциями, пусть хоть на берёзовых бруньках обмениваются, это договорённости сисопов. Большие инконсистентные эхи - это проблема, которая была решена изначально, но потом заменена на другое решение, для которой и потребовались слайсы, чем больше изменений, тем больше новых сущностей. Это всё - плохой дизайн.


idec.talks Выше Ответы Ответить