А что, если вообще оставить только /list.txt, (опционально) /blacklist.txt, /e, /m и /u/point? Тогда всё, кроме постинга, ложилось бы на физическую файловую структуру и его можно было бы сервачить хоть статикой.

revoltech> А что, если вообще оставить только /list.txt, (опционально) /blacklist.txt, /e, /m и /u/point? Тогда всё, кроме постинга, ложилось бы на физическую файловую структуру и его можно было бы сервачить хоть статикой.

Звучит прикольно, но очень неоптимизированно. Я тут хотел сделать конвертер который создаст эху с 37к+ сообщениями. Насколько долго будет получать индекс и сообщения?

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

doesnm> Звучит прикольно, но очень неоптимизированно. Я тут хотел сделать конвертер который создаст эху с 37к+ сообщениями. Насколько долго будет получать индекс и сообщения?

В первый раз будет долго (хотя зависит от канала у ноды и клиента), потом быстро. Мы же не перекачиваем вообще все сообщения каждый раз, а только те, которых не оказалось на клиенте.

Условно, алгоритм таков: выкачали индекс из /e/echo.name, сравнили с локальным содержимым того же файла, недостающие айдишники в цикле скормили /m, после успешного выкачивания перезаписали локальный индекс эхи.

revoltech> В первый раз будет долго (хотя зависит от канала у ноды и клиента), потом быстро. Мы же не перекачиваем вообще все сообщения каждый раз, а только те, которых не оказалось на клиенте.
revoltech> Условно, алгоритм таков: выкачали индекс из /e/echo.name, сравнили с локальным содержимым того же файла, недостающие айдишники в цикле скормили /m, после успешного выкачивания перезаписали локальный индекс эхи.

Мы не перекачиваем сообщения, но мы перекачиваем индекс. Сколько он будет весить с без адаптивного фетча?

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

doesnm> Мы не перекачиваем сообщения, но мы перекачиваем индекс. Сколько он будет весить с без адаптивного фетча?

777к. Если по HTTP с gzip, то гораздо меньше. Надо тестить.

doesnm>> Мы не перекачиваем сообщения, но мы перекачиваем индекс. Сколько он будет весить с без адаптивного фетча?
revoltech> 777к. Если по HTTP с gzip, то гораздо меньше. Надо тестить.

Что еще прикольно: это идеально ложится на тип базы txt (так и задумано изначально?)
Так что можно использовать утилиты из ii-db-utils и прочее

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

doesnm> Что еще прикольно: это идеально ложится на тип базы txt (так и задумано изначально?)
doesnm> Так что можно использовать утилиты из ii-db-utils и прочее

В глаза не видел этих утилит, но да, я ж говорю, если оставить только /list.txt, /e и /m, то всё можно сервачить статикой. А динамической только логику постинга через /u/point сделать.

revoltech> В глаза не видел этих утилит, но да, я ж говорю, если оставить только /list.txt, /e и /m, то всё можно сервачить статикой. А динамической только логику постинга через /u/point сделать.

Я про эти утилиты: https://github.com/idec-net/ii-db-utils
Тут даже есть скрипт чтобы конвертировать почту в ii формат

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

revoltech> В глаза не видел этих утилит, но да, я ж говорю, если оставить только /list.txt, /e и /m, то всё можно сервачить статикой. А динамической только логику постинга через /u/point сделать.

Либо если упороться, то кидать сообщения через rsync по ssh немного переделав https://github.com/idec-net/iissh
Кто сказал что мы обязаны постить только через /u/point ?

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

/z а затем и /u был введён потому что по одному слишком медленно было

А изначально и было только e и m

ahamai> /z а затем и /u был введён потому что по одному слишком медленно было

Но при этом зачем-то ограничиваем количество айдишников в /u/m.

> Но при этом зачем-то ограничиваем количество айдишников в /u/m.

я уже объяснял. это принцип разумной достаточности

1. разница между 1 и 20 в 2014 была ощутима, а между 20 и 40 - нет

2. большой запрос ставил колом однопоточный сервер

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

ahamai> /z а затем и /u был введён потому что по одному слишком медленно было
ahamai> А изначально и было только e и m

Некропост
Я тут подумал, а что если сделать /e и /m директориями, list.txt, blacklist.txt и т.д как есть, а все /u эндпоинты реализовать через openresty или mod_magnet написав на Lua?

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?