Обнаружил на сабже одно порченное сообщение в ii.test.14 ii://FbYeDw3FpA64o9g2ga20
Самое интересное не это, а то, что на моих станциях оно отсутствует вопреки блэклисту (и фетчер не давал ни единого предупреждения, что его не пускает).

Ещё более странное дело с /x/file. Подключившись к Таверне через свой клиент, обнаруживаю, что не могу получить список файлов.
Провернув небольшой дебаг, выяснил, что нода даёт пустой ответ. Подумав, что косяк на моей стороне (CutieFeed), проделываю аналогичный запрос через Curl:

curl --data-binary "pauth=my_authstr" http://idec.spline-online.tk/x/file

и получаю ... пустую строку, хотя по идее здесь должен был быть список файлов. Если добавить параметр filename, то всё работает.

curl --data-binary "pauth=my_authstr&filename=ic_robot.jpg" http://idec.spline-online.tk/x/file
# содержимое файла

Это не первая странность с /x/file. Проверив через браузер, обнаруживаю, что при запросе /x/file/filename выдаётся содержимое файла (хотя по стандарту так не должно быть), но при этом при запросе /x/file/random_string/filename нода шлёт пустоту, хотя файл публичный. При неверном authstr нода должна запретить вывод скрытого файла, но не публичного.

Такие вот дела.

vit01> Обнаружил на сабже одно порченное сообщение в ii.test.14 ii://FbYeDw3FpA64o9g2ga20

Спасибо. Посмотрю.

vit01> Ещё более странное дело с /x/file. Подключившись к Таверне через свой клиент, обнаруживаю, что не могу получить список файлов.

vit01> и получаю ... пустую строку, хотя по идее здесь должен был быть список файлов. Если добавить параметр filename, то всё работает.

Что странно, так как я спокойно его получаю. Надо будет снаружи проверить, но это только в среду смогу.

vit01> Это не первая странность с /x/file. Проверив через браузер, обнаруживаю, что при запросе /x/file/filename выдаётся содержимое файла (хотя по стандарту так не должно быть)

Вот тут поподробней. Судя по стандарту он так и должен себя вести в случае с публичным файлом.

vit01> но при этом при запросе /x/file/random_string/filename нода шлёт пустоту, хотя файл публичный. При неверном authstr нода должна запретить вывод скрытого файла, но не публичного.

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

vit01> Такие вот дела.

ЗЫЖ Таверна это вообще загадочное место. Иногда здесь случаются поистинне мистические вещи.

vit01> Самое интересное не это, а то, что на моих станциях оно отсутствует вопреки блэклисту (и фетчер не давал ни единого предупреждения, что его не пускает).

Забавное дело. Если сделать запрос на таверну в вот таком формате, как делает мой фетчер:

http://idec.spline-online.tk/u/e/game.rogue.14/ru.humor.14/lor-opennet.15/linux.14/ii.test.14/lit.14/pipe.2032/ii.14/habra.16/mlp.15/ifiction.15/piratemedia.rss.15/lenta.rss/python.15/creepy.14/develop.16/edgar.allan.poe/ii.stat/-200:200

, то этого странного айдишника в списке нет.

Если же убрать из запроса эху game.rogue.14, то он вдруг появляется. Тьфу, чёрная магия какая-то.

# на предыдущем сообщении, на которое сейчас отвечаю, регулярки веб-интерфейса таверны сломались

Что-то у них не то. Пришлось тикет завести.
Буду переезжать на хетцнер. Там 4Гб памяти за те же деньги. Эластику будет там хорошо.

А теперь 502 выдаёт.

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

vit01> # на предыдущем сообщении, на которое сейчас отвечаю, регулярки веб-интерфейса таверны сломались

Вот это уже пофиксил. С остальным пока не могу разобраться.

Поднялся

AL> А как быть, если у пользователя отсутствует поинт на ноде? Не надо забывать про GET-запросы всё таки.

На этот случай тоже всё предусмотрено. "Собаку съел" на /x/file, что называется.
Возьмём, к примеру, сообщение из пайпа про фоточки с прогулки: ( ii://flYdgHRQTACMOc9kW4KW )

vit01> Если что, вот браузерная ссылка: http://ii-net.tk/ii/ii-point.php?q=/x/file/none/2016-04-16.tar.xz

Когда человек запрашивает публичный файл (даже не являясь поинтом), то он имеет право ставить в поле authstr всё, что захочет. В данном случае стоит "none", но можно хоть "blablabla" поставить, и mira station всё равно отдаст файл. Если файл публичный, то нода authstr просто не будет проверять.

AL> Только сперва таки надо разобраться что пользователь должен слать в GET-запрос.

Можешь алгоритм посмотреть: https://github.com/vit1-irk/ii-php/blob/master/ii-point.php#L167

vit01> Что ж, лучше поздно, чем никогда.

Спасибо тебе, добрый человек =)

vit01>> Это не первая странность с /x/file. Проверив через браузер, обнаруживаю, что при запросе /x/file/filename выдаётся содержимое файла (хотя по стандарту так не должно быть)

AL> Вот тут поподробней. Судя по стандарту он так и должен себя вести в случае с публичным файлом.

Неа. Судя по стандарту, третьим параметром всегда должна идти authstr.
Цитата http://ii-net.tk/idec-doc/?p=extensions

> POST /x/file или GET /x/file/pauth/filename
> Параметры в теле запроса: pauth и filename. pauth - строка авторизации, filename - имя скачиваемого файла.

> Если filename отсутствует, то выдаёт список публично доступных файлов в формате <Имя>:<размер в байтах>:<Описание>. Если параметр pauth верный (существует поинт с таким паролем), то добавляет к "публичному" списку также скрытые от посторонних глаз файлы.

Если человек сделал запрос /x/file/string, то нода должна проверить правильность authstr и вывести на экран список файлов, причём не только публичных, но и "приватных".

Мы же при формировании стандарта договорились сделать возможность размещать как файлы только для поинтов, так и файлы для всех остальных.

AL> Что странно, так как я спокойно его получаю. Надо будет снаружи проверить, но это только в среду смогу.

Через ту самую curl-команду, что я написал?

CutieFeed работает c /x/file исключительно через POST-запросы, так что вполне может быть, что конкретно твои скрипты работают (если они под GET заточены).

AL> Лично я, когда предлагал эту схему, предполагал переменное количество параметров в зависимости от того, что пользователь передаёт. Чтобы хоть wget'ом, хоть через браузер мог быстро и понятно получить файлы.

А так разве медленно и непонятно? При нынешнем подходе оно хотя бы работает и выполняет поставленные задачи.
Можно поменять местами pauth и filename, но в таком случае будет неудобно получать список файлов.

vit01> Неа. Судя по стандарту, третьим параметром всегда должна идти authstr.

vit01> Если человек сделал запрос /x/file/string, то нода должна проверить правильность authstr и вывести на экран список файлов, причём не только публичных, но и "приватных".

vit01> Мы же при формировании стандарта договорились сделать возможность размещать как файлы только для поинтов, так и файлы для всех остальных.

А как быть, если у пользователя отсутствует поинт на ноде? Не надо забывать про GET-запросы всё таки.

Я сейчас туда заглянул и ужаснулся. x/file надо переделывать с нуля, можно сказать. Что-то я там такую чушь наворотил. Только сперва таки надо разобраться что пользователь должен слать в GET-запрос.

vit01> А так разве медленно и непонятно? При нынешнем подходе оно хотя бы работает и выполняет поставленные задачи.

Ну так и без расширенной u/e оно хотя бы работало. И выполняло поставленные задачи. Надо думать об удобстве.

vit01> Можно поменять местами pauth и filename, но в таком случае будет неудобно получать список файлов.

Да там одно простое условие. Просто я писал как всегда перед сном и потому там лажа у меня в коде. Но я не настаиваю. Стандартом по факту занимаешься ты. Если считаешь, что надо всегда указывать authkey, даже если его нет, то сделаем так. Просто я и так и этак смотрю на такой подход, а он мне всё равно не нравится.

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

vit01> Возьмём, к примеру, сообщение из пайпа про фоточки с прогулки: ( ii://flYdgHRQTACMOc9kW4KW )

vit01>> Если что, вот браузерная ссылка: http://ii-net.tk/ii/ii-point.php?q=/x/file/none/2016-04-16.tar.xz

vit01> Когда человек запрашивает публичный файл (даже не являясь поинтом), то он имеет право ставить в поле authstr всё, что захочет. В данном случае стоит "none", но можно хоть "blablabla" поставить, и mira station всё равно отдаст файл. Если файл публичный, то нода authstr просто не будет проверять.

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

Лично я, когда предлагал эту схему, предполагал переменное количество параметров в зависимости от того, что пользователь передаёт. Чтобы хоть wget'ом, хоть через браузер мог быстро и понятно получить файлы.

// Я ещё подумаю, а пока x/file в таверне можете считать нерабочей.

AL> Если считаешь, что надо всегда указывать authkey, даже если его нет, то сделаем так. Просто я и так и этак смотрю на такой подход, а он мне всё равно не нравится.

Ну а что бы ты предложил в альтернативу? Тут два варианта: либо GET-запросы не работают с приватными файлами, либо оно выглядит "некрасиво".

Мне-то всё равно, у меня клиент в любом случае работает только через POST (а кроме нас двоих сабжем в принципе никто не пользуется), так что пробуй, решай, как удобнее будет.

vit01> Вот почесал репу и придумал вариант, который устроит нас обоих. Можно разделить /x/file на 2 схемы: одна для списка, другая для скачивания.

Сделал в таверне такой вариант. Попробовал его и с GET и с POST запросами. Понравилось. Пока из всего, что мы надумали, этот вариант мне нравится более всего.

vit01> Проблема в том, что нода должна как-то различать authstr и имя файла. Вот отправил ты запрос /x/file/string, а нода должна думать: ты поинт и хочешь получить список, или ты файл с именем string скачать хочешь? Забавные вещи будут выходить, если в конфиге есть и файл с таким названием, и поинт с таким authstr.

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

vit01> Вот почесал репу и придумал вариант, который устроит нас обоих. Можно разделить /x/file на 2 схемы: одна для списка, другая для скачивания.

vit01> ====
vit01> GET /x/filelist
vit01> # публичные файлы

vit01> GET /x/filelist/pauth
vit01> # публичные + приватные файлы, если authstr верный

vit01> GET /x/file/filename
vit01> # публичный файл или ошибка

vit01> GET /x/file/pauth/filename
vit01> # приватный (или публичный) файл или ошибка, различие
vit01> # с предыдущим запросом определяется по количеству параметров
vit01> ====

Вот такой вариант стройнее и красивее. И надо решать вопрос пока ещё этой фичи толком нет нигде.

vit01> Да к чёрту этот авторитет. Мы же технические вопросы обсуждаем, а здесь такие нелепости никакого значения не имеют.

Я тут понял на примере того же инстеда, что разработка стандарта должна опираться на два столпа: непротиворичивость и диктаторства. Иначе начнётся элементарный хаос. Потому я и признаю авторитет, потому и мусолю эту тему с файлами так муторно.

vit01> Так изменяем или не изменяем саму схему? Вообще, POST у тебя точно сломанный, а насчёт GET надо сейчас до конца решить.

Я сегодня постараюсь найти время на исправление ноды.

Кстати, отправил тебе недавно исправление к патчу для андроида. Слей пулл-реквест, пожалуйста.

AL> Видимо, у нас разное представление о "прекрасном" просто. Мне нравится идея, что третий параметр может быть или authkey или именем файла и нода в зависимости от этого отдаёт соответствующую информацию.

Проблема в том, что нода должна как-то различать authstr и имя файла. Вот отправил ты запрос /x/file/string, а нода должна думать: ты поинт и хочешь получить список, или ты файл с именем string скачать хочешь? Забавные вещи будут выходить, если в конфиге есть и файл с таким названием, и поинт с таким authstr.

Вот почесал репу и придумал вариант, который устроит нас обоих. Можно разделить /x/file на 2 схемы: одна для списка, другая для скачивания.

GET /x/filelist
# публичные файлы

GET /x/filelist/pauth
# публичные + приватные файлы, если authstr верный

GET /x/file/filename
# публичный файл или ошибка

GET /x/file/pauth/filename
# приватный (или публичный) файл или ошибка, различие
# с предыдущим запросом определяется по количеству параметров

AL> С учётом того, что ты с моей точки зрения больший авторитет имеешь в вопросах стандарта, так как ты больше для него и нашей сети сделал, твоё видение более правильное =)

Да к чёрту этот авторитет. Мы же технические вопросы обсуждаем, а здесь такие нелепости никакого значения не имеют.

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

Так изменяем или не изменяем саму схему? Вообще, POST у тебя точно сломанный, а насчёт GET надо сейчас до конца решить.

vit01> Ну а что бы ты предложил в альтернативу? Тут два варианта: либо GET-запросы не работают с приватными файлами, либо оно выглядит "некрасиво".

Видимо, у нас разное представление о "прекрасном" просто. Мне нравится идея, что третий параметр может быть или authkey или именем файла и нода в зависимости от этого отдаёт соответствующую информацию.

vit01> Мне-то всё равно, у меня клиент в любом случае работает только через POST (а кроме нас двоих сабжем в принципе никто не пользуется), так что пробуй, решай, как удобнее будет.

Да не. Давай уже определимся. С учётом того, что ты с моей точки зрения больший авторитет имеешь в вопросах стандарта, так как ты больше для него и нашей сети сделал, твоё видение более правильное =) Просто пропиши этот момент в стандарт более однозначно, а я уж буду им руководствоваться при правке своей ноды.

vit01> Дело здесь не в самих ошибках в коде и коллизиях. Суть в костылях, которые надо нагромождать в исходниках, чтобы заставить это работать. Причём на разных нодах они могут приводить к разному поведению, и это очень неудобно.

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

vit01> Насчёт POST прошу уточнить, т.к. это важно. Мы делаем примерно такой вариант?

vit01> ====
vit01> POST /x/filelist
vit01> # публичный список

vit01> POST /x/filelist pauth=string
vit01> # приватный + публичный список, либо только публичный, если неверно

vit01> POST /x/file pauth=string, filename=string2
vit01> # содержимое файла, если pauth верный или filename публичный
vit01> # ошибка, если файла не существует
vit01> # ошибка, если файл приватный и pauth неверный

vit01> POST /x/file filename=string
vit01> # содержимое файла, если публичный
vit01> # в ином случае ошибка
vit01> ====

Вроде да. По крайней мере тесты в таверне дают именно такое поведение и именно так я понял изначальный посыл с двумя схемами.

AL> Вроде да. По крайней мере тесты в таверне дают именно такое поведение и именно так я понял изначальный посыл с двумя схемами.

Тогда ещё надо бы будет уточнить в стандарте, что POST-запросы имеют приоритет перед GET-ом.

Либо сегодня, либо завтра поправлю собственную ноду, стандарт и клиенты.

AL> Вероятность того, что authkey будет хотя бы напоминать имя ркального файла болтается где-то в районе нуля. У нас и коллизии в msgid могут запросто возникнуть, но с исчезающе малой вероятностью. Потому я считаю, что простой проверки по поинтлисту достаточно, чтобы определить что это пользователь передал.

Дело здесь не в самих ошибках в коде и коллизиях. Суть в костылях, которые надо нагромождать в исходниках, чтобы заставить это работать. Причём на разных нодах они могут приводить к разному поведению, и это очень неудобно.

vit01>> Вот почесал репу и придумал вариант, который устроит нас обоих. Можно разделить /x/file на 2 схемы: одна для списка, другая для скачивания.

AL> Сделал в таверне такой вариант. Попробовал его и с GET и с POST запросами. Понравилось. Пока из всего, что мы надумали, этот вариант мне нравится более всего.

Насчёт POST прошу уточнить, т.к. это важно. Мы делаем примерно такой вариант?

POST /x/filelist
# публичный список

POST /x/filelist pauth=string
# приватный + публичный список, либо только публичный, если неверно

POST /x/file pauth=string, filename=string2
# содержимое файла, если pauth верный или filename публичный
# ошибка, если файла не существует
# ошибка, если файл приватный и pauth неверный

POST /x/file filename=string
# содержимое файла, если публичный
# в ином случае ошибка

>А теперь 502 выдаёт.
Fixed

def _is_name(qq):
    return False
    # здесь надо зафигачить проверку, которая определяла бы
    # похоже ли написанное на имя или нет, но случаи типа
    # 5>2, -3>-4, 5*2+4>100-10 не вырезала


def _msg_filter(lines):
    out = []
    codestart = 0
    for n in lines:
        if n == '====':
            codestart = 1 - codestart
        if '>' in n and not codestart:
            qq, qline = n.split('>',1)
            if len(qq) < 21 and _is_name(qq):
                out.append('>' + qline)
            else:
                out.append(n)
        else:
            out.append(n)
    return out

честно говоря, чем больше смотрю на варианты, тем меньше понимаю, как её написать :(

ваши идеи?

>> если ты сделаешь опцию, чтобы такое цитирование отключалось - фильтр вообще можно будет выкинуть, потому что это остался единственный клиент, где такое поведение "насильно" :)
>Если такое цитирование у меня отключить, то сообщения перестанут выделяться цветом, а это крайне нежелательно для глаз.
>Да и вообще: ты хотя бы протестировал клиент, чтобы уже делать какие-то выводы? Присланная регулярка поддерживает как старые, так и новые цитаты, так что никто в пролёте не оказывается.
>А насчёт адаптации к ГК11 было написано ещё в этом сообщении: ii://F17PPvWlIqnmScZeagVo

причём здесь, как это выглядит? мне надо, чтобы имелась возможность НЕ ОТПРАВЛЯТЬ такие сообщения, при включении некоторой опции.

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

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

или я могу как-то опознать клиента, и вместо принятия сообщения написать "ваш клиент не поддерживается нашим гейтом"?

Попробуй регулярку из моего клиента

re.compile(r"^\s?[\w_А-Яа-я\-]{0,20}(>)+.+$", re.MULTILINE | re.IGNORECASE)

Вместо &gt; > ставишь, и всё

>> это третий python? что-то ни re.UNICODE, ни уникодизации строки

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

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

или ещё какие-то клиенты имеют эту "фичу" жёстко забитой?

RY> это третий python? что-то ни re.UNICODE, ни уникодизации строки

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

RY> если ты сделаешь опцию, чтобы такое цитирование отключалось - фильтр вообще можно будет выкинуть, потому что это остался единственный клиент, где такое поведение "насильно" :)

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

Да и вообще: ты хотя бы протестировал клиент, чтобы уже делать какие-то выводы? Присланная регулярка поддерживает как старые, так и новые цитаты, так что никто в пролёте не оказывается.

А насчёт адаптации к ГК11 было написано ещё в этом сообщении: ii://F17PPvWlIqnmScZeagVo

>Попробуй регулярку из моего клиента
>====
>re.compile(r"^\s?[\w_А-Яа-я\-]{0,20}(&gt;)+.+$", re.MULTILINE | re.IGNORECASE)
>====
>Вместо &gt; > ставишь, и всё

это третий python? что-то ни re.UNICODE, ни уникодизации строки

а вообще, проблемы лучше решать по мере их поступления: закоммитил с пустым фильтром, пока не возникло проблем - пусть всё пропускает.

Да, хочу сменить ЮзерАгент фетчера на umbrella/bot 0.x, все ноды корректно отдадут контент?

* Переехали в хетцнер
* Elasticsearch 2.3
* Теперь только SSL. HTTP реврайтится в HTTPS

TODO:

* Веб-интерфейс для расширенного поиска
* Открыть(BSD 3-clause) маппинг индекса

vit01> Все эти скобочки >>> или RY> вместе с самими цитатами пользователь выставляет ВРУЧНУЮ, через Ctrl-C, Ctrl-V, <что угодно>!
Про это говорили уже неоднократно, кстати. Опять будет эпопея про цитирование на месяц? :D

Difrex> Да, хочу сменить ЮзерАгент фетчера на umbrella/bot 0.x, все ноды корректно отдадут контент?

А ты проверь и расскажи.
ii-net.tk и alicorn.tk должны нормально отдавать, но насчёт irk39.tk не уверен (у openshift свои тараканы на серверах).

Зачем так менять, кстати? Если надо идентификацию, то можно просто в конец записать эту строку. И совместимость не пострадает, и цель выполнена.

RY> причём здесь, как это выглядит? мне надо, чтобы имелась возможность НЕ ОТПРАВЛЯТЬ такие сообщения, при включении некоторой опции.

Это уже какой-то режим советской цензуры получается :)

RY> - либо я вырезаю этот явно лишний и невнятный код, но при этом завтра какой-нибудь юзер узнаёт про этот гейт, качает клиента, начинает отвечать направо и налево, и потом улетает в бан по подсети, и даже не узнает, за что :)

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

Может быть, мы просто друг друга не до конца понимаем?
Вот нажимаю я кнопку "Ответить" в CutieFeed. Открывается Vim, Emacs, что угодно, и там:

ii.14
Roman Yakovlev
Re: пишу фильтр

@repto:L8cTAGBx6aKdxcAdR7uX

Все эти скобочки >>> или RY> вместе с самими цитатами пользователь выставляет ВРУЧНУЮ, через Ctrl-C, Ctrl-V, <что угодно>!

// Цезий, кстати, делает автоцитирование, но в моём клиенте этого нет и никогда не было

>// Цезий, кстати, делает автоцитирование, но в моём клиенте этого нет и никогда не было

да, видимо жаль, что я так и не смог его запустить

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

запустил и проверил клиент на py3-qt5

добавил его в архив ii-клиентов.

теперь там четыре клиента, официально одобренные :) для работы с гейтом:

старый caesium, новый caesium, 51talk и cutiefeed

постоянно обновляемый архив находится тут
http://gk11.ru/s/ii-clients.tar.gz

код "неправильного цитирования" с гейта удалён

>>основной принцип ii.
>У нас же уже не ii.

так я говорю про главу "сравнение с ii"

(я познаю сайт, часть третья) :)

> Когда в эхе накапливается по 3000 сообщений и более, получать индекс со станции становится долго.
> Из-за предыдущей причины приходилось "перекатывать" эхи, периодически переходя из одной в другую

Эхи не "приходится перекатывать". Эхи обязаны перекатывать, это основной принцип ii. При создании я его объяснял на примерах, задавая простой вопрос "а ты можешь найти архив RU.GAME за 1995 год?". Эха в ii должна быть целостной, у 99% нодов и пойнтов сообщения должны быть идентичными (различаться может только порядок). После чего эха конкретного года аккуратно тарболится и ложится в архив - чтобы хоть у кого-нибудь, но набор эхи за этот год остался. Потом, в следующем году, сообщения в новой эхе тоже постепенно растекаются по всем, чтобы за год все успели всех синхронизнуть - и снова в архив, чтобы через 20 лет можно было найти.

Это не достоинство и не недостаток, это фундаментальная основа проекта ii. Другое дело, что она не слишком применима, и смысла в этих архивах нет никакого :), поэтому ГК11 - это совсем иной принцип. Но если будет контент под задачу "хранить вечно", тогда ii ещё пригодится - поэтому архив с ii-final раздаётся прямо на странице загрузки ГК11 :)

>основной принцип ii.
У нас же уже не ii.

>эээ... а как вы решаете проблему "опознания", если вы от цифровых постфиксов отказались?
В названии эхи есть точка, в msgid - нет.

> Чтобы сослаться на эху или сообщение, дописываете перед ними ii://.
> Например, ii://pipe.2032 или ii://LzGnRCl9R0pwz6JHdShE.

эээ... а как вы решаете проблему "опознания", если вы от цифровых постфиксов отказались?

://dvadcatbukvesheesheo - это эха или сообщение?

>>эээ... а как вы решаете проблему "опознания", если вы от цифровых постфиксов отказались?
>В названии эхи есть точка, в msgid - нет.

всё, уже дочитал до этого места :)

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

слово "фетч" пришло не из фидо, там и слова-то такого не было... честно говоря, я уже забыл, как оно там называлось - полл, по-моему, менее склерозные фидошники пусть меня поправят :)

слово "фетч" я взял из OpenBSD, потому что постоянно занимался там фетчингом :) в смысле, make fetch в портах, а точнее - dpb -F #

RY> эээ... а как вы решаете проблему "опознания", если вы от цифровых постфиксов отказались?

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

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

ясно. не, я иначе сделал - у меня идентификаторы эх начинаются с :
я почему-то думал, что вы тоже от точек отказались

RY> теперь там четыре клиента, официально одобренные :) для работы с гейтом:

Зря одобрял. Ну раз всё-таки записал, то не забудь уточнить, чтобы пользователи снимали галочки в настройках "Включить схему /x/c" и "Поддержка расширенного /u/e", иначе фетчер для классических ii-станций работать не будет.