vit01>> Насчёт /u/point через POST запросы не понимаю, о чём ты. Оно и так в большинстве реализаций через POST пашет, см. в первоисточники.
vit01>> https://github.com/idec-net/ii-db-utils/blob/master/sender.py
vit01>> https://ii-net.tk/idec-doc/?p=protocol

AL> В стандарте этого нет.

Вот я тебе скинул ссылку на стандарт, на нашу же документацию, там чётко написано, процитирую ещё раз:

> GET /u/point/pauth/tmsg или POST /u/point
> ...
> В случае POST параметры называются так же: pauth и tmsg.

Поддержка POST была всегда, ещё со времён Ромы.

Можешь глянуть вот сюда, это первая версия ii-php, коммит от 6 апреля 2014, даже тут оно есть, потому что в стандарте было зашито изначально:

https://github.com/idec-net/ii-php/commit/c5b7d89b28520d189631f20a72deb0c4a9c35054

vit01>> Клиенты не будут переваривать огромные сообщения и начнут тормозить (IDEC Mobile уже подтормаживает на больших рассказах из lit.14 и creepy.14). А ещё появляется риск засорения базы данных на серваке.

AL> Если программа тормозит от 64 килобайт текста, то значит с программой что-то не так. А засрать базу никто не мешает и так. Скрипт пишется на коленке и можно тысячи сообщений отправить по несколько десятков байт каждое. И это будет большим уроном, чем одно сообщение в мегабайт.

Клиент занимается парсингом цитат, блоков кода, подсветки и так далее. Построчно, на регулярных выражениях. И не забывай, что sqlite не очень шустрый, особенно на мобилках. Чтобы грузить все сообщения мгновенно, придётся грузить их все фоном в ОЗУ (потребление вырастет очень сильно), и для сообщений каждое в мегабайт 20-30 обход регулярными выражениями - вещь крайне печальная. CutieFeed делает синхронные запросы в базу, а IDEC Mobile - заранее, опережая пользователя на одно сообщение. Но, тем не менее, репарсинг и рендеринг в HTML заставляет и его на больших сообщениях подтормаживать.

Насчёт урона тысячи сообщений по десятку байт. Больше опасаюсь, что спамеры будут слать тысячи сообщений по десятку мегабайт, а не байт.

Просто если я вижу, что клиент начал скачивать 10 000 сообщений, то сразу же могу прибить клиент (отказаться от получения), потому что знаю, что каждое из этих сообщений не превышает 64 килобайта. Если приходит 100 сообщений каждое размером до 10-20 мегабайт, то ты плохо понимаешь, что там внутри. И обнаруживаешь, что клиент жрёт гигабайты трафика, уже ПОСЛЕ того, как эти сообщения скачал. Это утеря контроля пользователя над своим трафиком и над своими ресурсами.

vit01>> Если у поинта есть дневной лимит на количество сообщений, то мы точно знаем, что он за 1 день не вылетит за лимит в N мегабайт.

AL> А если нет? Моя нода, например, не имеет и не будет иметь такого ограничения. Если же это защита от случайных флудеров на узлах с авторегистрацией, то регистрацию можно также проходить автоматически и срать в сеть тысячами мусорных сообщений. Урон по прежнему будет больше, чем одно сообщение в мегабайт.

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

Не будет одного сообщения в мегабайт. Будут сразу же 1000 сообщений по 10 мегабайт каждое, и твой клиент упадёт, прогружая их все в оперативку и раскрашивая цитаты. Или будет так тормозить, что им невозможно будет пользоваться.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM