Складывается впечатление, что idec это пример плохого проектирования. Зачем менять устоявшуюся структуру запроса /u/e если можно этого не делать? Зачем вводить ограничение "количество сообщений в эхе может не совпадать со счётчиком", если можно этого не делать?

Формат /u/e был именно только для списка эх. Зачем добавлять туда что-то ещё? Почему не использовать, например /u/e?s=срез? Это значительно всё упрощает, это можно сувать куда угодно без разбора. А так алгоритм отдачи "всё эха" меняется на "последняя эха может быть не эхой":

ВЕСЬ ЗАПРОС СПИСОК ЭХ
ПОЛУЧИЛИ СПИСКИ
ЕСЛИ ЕСТЬ ЛИМИТ, УСТАНОВИЛИ

становится

ПОЛУЧИЛИ СПИСОК ЭХ
ПРОВЕРИЛИ ПОСЛЕДНЮЮ
ЕСЛИ ЭТО СРЕЗ, ТО РАСПАРСИЛИ СРЕЗ
СОХРАНИЛИ ЛИМИТ
УДАЛИЛИ ПОСЛЕДНЮЮ ЭХУ
ПОЛУЧИЛИ СПИСКИ
УСТАНОВИЛИ ЛИМИТ, ЕСЛИ ЕСТЬ

Команда lim появилась добавлением одного роута и одной строчки кода. Совместима с любым ii, хоть с ii-txt-0.1preprepre.

При этом корёжится список:
http://ii.blcat.ru/u/e/blcat.test/-100:100

ЧТО ТЫ ТАКОЕ? Эха? Нет точки, не эха. MSGID? по логике вроде бы да. У меня софт в расчёте на минималистичность и читаемость кода призван валиться при любых невалидных данных, а не разбираться, что это за ёжик.

Тут же появляется x/features. Это на каждый фетч надо ещё один запрос делать? Это не экономия трафика, это его расход. С какой-нибудь ?s= можно просто гонять url-ы и на любой клиент и на любой сервер, не задумываясь, поймёт ли он. А тут получается, надо прочитать x/features, потом подстроиться под сервера, давать ему срез или не давать. Лишний код, лишний трафик, лишнее переусложнение.

Сами же срезы не решают основной задачи "получить все нужные msgid одним запросом". Тебе нужно или обходить эхи по-очереди (привет, /e, от которого специально уходили для ускорения работы), или получать лишние сообщения. В стандарте не предусмотрено "хочу брать столько сообщений оттуда-то".

Кстати, ?sf потребовал добавления, по-моему, 4х строк кода и изменения одной. И он решает вопрос "получить только нужные msgid из нужных эх одним запросом".

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

Куча переусложнений там, где их можно было не делать, и при этом основная цель минимизации трафика до конца не доведена. Это пример плохого проектирования, как по мне.

ps. ?sf и ?h появились раньше, чем был сформирован стандарт iDEC.

> Ещё есть вариант найти мастера,

тут новые пользователи появляются раз в пятилетку... :)

тем более что sokoban игра с полной информацией и ходами только с одной стороны, её можно пройти одной командой

по одному ходу скучно, надо сразу по много

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

Ещё есть вариант найти мастера, сыграть в D&D.

P.S. Чур я бард-человек.

кривая и косая версия adventure. играть можно только на моей станции

http://ii.blcat.ru/play.advent

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

Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи. Почему не использовать что-то типа ?s=-100:100 или любой другой способ? Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения. Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?

Ладно, раз уж решили изнасиловать формат /u/e, почему не использовать /u/e/эха/срез/эха/срез. Это же для экономии трафика всё затевалось? А какая экономия, если у тебя может быть куча эх, и ради одной роботной, где всегда куча сообщений, тянется куча ненужных? А если поодиночке - то это лишние запросы, на медленном и нестабильном интернете каждый запрос это всегда больно, и он может даже не состояться (поэтому links решал там, где opera не могла ни одного сайта открыть). Формат /u/e был придуман ровно для того, что дёргать /e на каждую эху было медленно и неэффективно. Изначально были только /e и /m, но всё это было медленно и печально.

> Можно передавать уровни сокобана в plaintext-формате (.sok).

А если и играть через эху? ;)

- если сообщений в базе мало
+ если новых сообщений в эхах разное количество, непонятно почему просто не запрашивать с каждой нужное (ну, или, с гарантией +1, +5 сообщений, это небольшой оверхед, по сравнению со случаем когда опращиваются одним запросом эхи с 1 и 110 сообщениями)
111
Вообще, связка h и sf реально сокращает количество запросов и реально экономит трафик. Если это кому-то важно.

> Можно передавать уровни сокобана в plaintext-формате (.sok).

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

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

реализация и sf и lim у меня это всего несколько строчек.

было

def echoareas(names):
    out = ''
    for ea in names:
        out += ea + '\n' + get_echoarea(ea,True)
    return out

стало

def echoareas(names, sf, lim=0):
    out = ''
    if sf: sf = set(sf.split('/'))
    for ea in names:
        dllist = get_echoarea_f(ea)
        if sf:
            newhash = [x for x in dllist if x in sf]
            if newhash:
                dllist = dllist[dllist.index(newhash[0]):]
        if lim: dllist = dllist[-lim:]
        dllist = '\n'.join(dllist)
        if dllist: dllist += '\n'
        out += ea + '\n' + dllist
    return out

не использовалось это никогда потому что я не вижу смысла экономить и так копеечный трафик. но на такой случай реализация в моей станции была

tuple> А ещё можно передавать сохранения игр, проходя их по очереди. Те же дварфы (dwarf fortress). Много чего можно сочинить.

Можно передавать уровни сокобана в plaintext-формате (.sok).

tuple> А ещё можно передавать сохранения игр, проходя их по очереди. Те же дварфы (dwarf fortress). Много чего можно сочинить.

У нас нельзя передавать файлы в общем случае. Да и бородачи нынче не те. Я так и не освоил новый интерфейс.

+++ Caesium/0.4 RC1

А ещё можно передавать сохранения игр, проходя их по очереди. Те же дварфы (dwarf fortress). Много чего можно сочинить.

ahamai> у меня sf работает так: запрос вида /u/e/эха1/эха2/эха3?sf=хэш1/хэш2/хэш3, и она ищет указанные хэши в эхах, если находит, начинает выдачу эх с них. сначала не вклчая сами хэшN, но несколько дней назад я сделал, чтобы включали, на всякий случай, 21 байта не жалко, зато можно убедиться, какой именно хэш

А если хеш в блеклисте или вообще удалён? Ну и сложно это в реализации и не особо незачем.

+++ Caesium/0.4 RC1

>> По хорошему особый сисоповский должен быть. Потому что пуш для межузлового взаимодействия. Поини в принципе не может слать пуш, так как в пуше уже зарегистрированные сообщения летят, а не пользовательские.
shaos> Может тогда как-то почётче это в стандарте про push проговорить?

Хорошо. Принимается.

+++ Caesium/0.4 RC1

ahamai> Тогда не понял, почему стандарт такой, если в каждой эхе разное количество новых сообщений. :) Ладно, поняли-разобрались. Стандарт читал но как-то не задумывался об этом, задумался только сегодня в тронвае :)

Потому что не надо байто**ить. Сильно помогает в подавляющем числе случаев.

ahamai> 2shaos - фетчеры обновил

+++ Caesium/0.4 RC1

ahamai> Ничё не понял. Если щас задать несколько эх и дать срез, он со всех по n сообщений запросит или только с последнего

Со всех, если я правильно понял типавопрос.

+++ Caesium/0.4 RC1

у меня вроде вообще не было стандарта на push, я его и не поддерживал, но в push-нодах всегда был отдельный пароль

push-ноды для меня были как партизанские станции, которые раскидываешь по бесплатным php-хостингам и с ними живёшь. на серьёзных станциях он не был предусмотрен, потому что серьёзные станции только фетчат и на них нельзя что-то вливать

Ну и всё это сделать эксклюзивом нашей сети. Я помню, как году в 1997 играли в дюк нюкем на одной клавиатуре толпой, кто-то отвечал за стрельбу, кто-то за прыжки, кто-то за передвижение. Это было весело. И так, можно толпой проходить игру, и больше ответственности, и больше интереса.

Ага. Интересно. А что если играть в текстовые игры на instead? Я за последние лет 15 или сколько там, прошёл ровно одну игру, "День яблока". Остальные не осилил. Кота и ещё несколько игр прошёл только по солюшнам, потому что сам даж не знал чё там и где.

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

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

Может тогда как-то почётче это в стандарте про push проговорить?

А через ping?

https://hugeping.tk/forum/c8zTIjCQQ1RyAA264WnN/1

Странно - линк не открывается:

http://tgistation.ru/echo/subj/8/%D0%98%D0%B3%D1%80%D1%8B%2520%D0%BF%D0%BE%2520ii%2520/

да, я так и поставил, вроде всё работает как и задумано

ну как минимум в беседке была викторина, основаная на каком-то irc-боте, типа даёт вопрос и вариант п****ц, потом открывает буквы

у меня тред 404 выдаёт. подними тему, чтобы на hugeping в форумах высвечивалась :)

Вот тут я пытался это пообсуждать месяц назад:

ii://c8zTIjCQQ1RyAA264WnN

Вот тут можно тред поглядеть:

http://tgistation.ru/echo/subj/8/%D0%98%D0%B3%D1%80%D1%8B%2520%D0%BF%D0%BE%2520ii%2520/

P.S. Надо у меня чтоли тоже показ тредов поддержать, но только не линейно, а деревом - как на ixbt было или как комменты на слешдоте например…