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

# revoltech to ahamai @ Re: Полуневдимые эхи @ idec.talks 25/10/24 09:03

ahamai> Идея в том, что есть и библиотеки, и средсва в системе, и можно с плмощью wget, cat и такой то матери в три строчки собрать простейший клиент.

Намёк был на то, что есть транспорты ещё проще, чем HTTP. Например, Nex/NPS можно вообще описать парой коротких предложений:

1. Скачивание (Nex): отправляем путь и LF на TCP-порт 1900, забираем данные.
2. Постинг (NPS): отправляем путь и LF, опционально строку авторизации и LF, сами данные, LF, точку (.) и LF на TCP-порт 1915, забираем ответ.

Всё, это оба протокола. Дальше в Nex расписано, что рекомендуется делать на клиенте, если путь заканчивается на /, но к ii это уже можно не применять. Вместо LF можно использовать CRLF, как минимум существующие сервера это понимают.

Суть именно в простоте, даже на оф.сайте указано сверху, как через nc выгрести Nex-ресурс:

echo nps/info/form.txt | nc nightfall.city 1900 | less

С гофером, кстати, точно так же, только порт по умолчанию 70. Но нет, давайте городить огород с ненужными для ii HTTP-хедерами, лимитами на гет-запросы и контент-тайпами.

Если что, не осуждаю существующие подходы, просто не понимаю, почему бы опционально не сделать ещё проще.

ahamai> Лимит на get у меня вроде тоже 8 кб

Это типа «640 кб хватит всем»? :D Ну ладно, поставил тоже 389 на запрос. Как-нибудь попробую перефетч. А у остальных как? У пинга понятно, нжинкс и 12 сообщений на запрос максимум. А у spline-online и tgistation что?



# hugeping to revoltech @ Re: Полуневдимые эхи @ idec.talks 25/10/24 09:28

revoltech> У пинга понятно, нжинкс и 12 сообщений на запрос максимум.

У меня нет веб сервера. Насчёт 12 сообщений, интересный вопрос. Это проверено? Я посмотрю, может быть это можно настроить в go библиотеке.



# ahamai to revoltech @ Re: Полуневдимые эхи @ idec.talks 25/10/24 10:18

Это понятно, но меня http полностью устраивает по ресурсоёмкости, распространённости везде и для всего, веб-фреймворков для него.

Ну и есть всякие плюшки типа минимальной гарантии доставки (content-len, или если что-то пошло не так, брякнулись с ошибкой и клиент понял что ошибка). Плюс опциональное gzip сжатие, существующее с лохматых годов. Правда, сейчас py3 фетчер не поддерживает gzip сжатие, py2 и ii-txt на py2 поддерживают. Сейчас глянул, у меня на сервере не включён gzip для text/plain, включил.

Это хорошо и замечательно, если будут другие транспорты. Но подразумевается, что протокол настолько простой то эти транспорты пишет тот, кто этим интересуется. Для меня простота - это возможность в несколько строк написать фетчер хоть на python, хоть на busybox, поэтому я буду поддерживать реализацию только через http. Но всегда интересно посмотреть на сторонние проекты.