Обновился дефолтный сервер на питоне.

Добавлен расширенный интерфейс /x. Текущая реализация содержит только метод /x/mtime, который возвращает время модификации эхи. На входе список, на выходе список вида

echoname1:mtime1
echoname2:mtime2

>Добавлен расширенный интерфейс /x. Текущая реализация содержит только метод /x/mtime, который возвращает время модификации эхи. На входе список, на выходе список вида

Кстати, насчет списков. Мне не нравится / как разделитель. В урле. Вот вообще.

> Добавлен расширенный интерфейс /x. Текущая реализация содержит только метод /x/mtime, который возвращает время модификации эхи. На входе список, на выходе список вида
Почему /x? Стандарты надо чётко продумывать. Не лучше ли было сделать /u/t или просто /t? Хотя, наверное, это просто мои придирки.

> Кстати, насчет списков. Мне не нравится / как разделитель. В урле. Вот вообще.
А по-моему, удобно. Но base64 urlsafe добавляет свою специфику.

>Кстати, насчет списков. Мне не нравится / как разделитель. В урле. Вот вообще.

Плюсую! То же не нравится.

>> Добавлен расширенный интерфейс /x. Текущая реализация содержит только метод /x/mtime, который возвращает время модификации эхи. На входе список, на выходе список вида
>Почему /x? Стандарты надо чётко продумывать. Не лучше ли было сделать /u/t или просто /t? Хотя, наверное, это просто мои придирки.

Потому что eXtended API. Если примем в стандарт, то можно и /u.
Я бы еще уточнил интерфейс, сгруппировать методы по группам, /e/<method> для эх, /m/ для сообщений и т.д.

>> Кстати, насчет списков. Мне не нравится / как разделитель. В урле. Вот вообще.
>А по-моему, удобно. Но base64 urlsafe добавляет свою специфику.

Удобно, но не очень логично, а я не люблю, когда нелогично. Поясню:
/u/e/name/name/name... - где namespace, где метод, где параметры, сколько параметров? Всё в кучу.

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

Всё правильно.

>Обновился дефолтный сервер на питоне.

Методы /list.txt и /blacklist.txt не являются частью стандарта, нигде не описаны и вообще.
Теперь они являются устаревшими и будут возвращать 'deprecated'.

Также устаревшими являются методы /e и /m, со временем они будут убраны.

Неймспейс /u пока под вопросом. Если оставлять обратную совместимость с существующими клиентами, то его придется оставить неизменным и делать новый, например /x.

В обновленном API разделителем списков будет '+', немного изменится интерфейс, будет добавлен метод для получения timestamp'а эхи.

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

Такова плата за децентрализованность

>Также устаревшими являются методы /e и /m, со временем они будут убраны.
God whyyyy?

>Неймспейс /u пока под вопросом. Если оставлять обратную совместимость с существующими клиентами, то его придется оставить неизменным и делать новый, например /x.

Я считаю что надо оставлять /u до последнего. Чтобы не пришлось в спешном порядке менять софт на узлах и на станциях поинтов. В конце концов это не столь обременительно.

>В обновленном API разделителем списков будет '+', немного изменится интерфейс, будет добавлен метод для получения timestamp'а эхи.

Вот это хорошо. Теперь можно будет не дёргать зазря списки и не выстраивать пустые diff'ы при каждом обмене. Одобрямс =)

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

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

>>Также устаревшими являются методы /e и /m, со временем они будут убраны.
>God whyyyy?

Потому что ещё при Романе они считались устаревшими? Всё равно все затачиваются на /u и тянуть это добро уже нет смысла. Вот /u я бы не спешил прибивать. Хотя бы до тех пор пока авторы живых клиентов не отпишутся о поддержки /x (или как там оно будет?).

Я не знал, что они устаревшие. Пилил свой клиент по документации.

Ну и как теперь правильно работать с этим всем? Какие будут методы поддерживаться? Как теперь правильно получить список мессаг в эхе?

Пришлось проснуться и ответить...
> Методы /list.txt и /blacklist.txt не являются частью стандарта, нигде не описаны и вообще.
> Теперь они являются устаревшими и будут возвращать 'deprecated'.
Это не методы, это внутренние файлы ноды, их вообще не надо показывать наружу, поэтому убирай (и можно даже без депрекатед).

> Также устаревшими являются методы /e и /m, со временем они будут убраны.
/e убирай, так как оно практически дублирует поведение /u/e, а вот /m убирать не надо, так как оно полезно для отладки.

> Неймспейс /u пока под вопросом. Если оставлять обратную совместимость с существующими клиентами, то его придется оставить неизменным и делать новый, например /x.
Не надо убирать! Если нужно новые функции, то лучше добавить их в /x

> В обновленном API разделителем списков будет '+', немного изменится интерфейс
Ну почему плюс? Со слешем же всё нормально было, зачем переусложнять?

> Что касается ротации, всё чуть сложнее, чем кажется, но реализуется довольно просто.
С ротацией разберёмся позже, сейчас усложнять стандарт не надо.

И да, почему вдруг стандарты так быстро меняются? А спросить, нужно или не нужно? А сообщество наше?

Ок, разобрался c /u/.

Как оно будет с методом /x/? И когда появится на серверах? Ну, чтобы знать, когда перестанет все работать

>Ну и как теперь правильно работать с этим всем? Какие будут методы поддерживаться? Как теперь правильно получить список мессаг в эхе?

Для этого есть метод /u. Зайди ко мне на страничку узла и добавь в адресной строке после /ii/ii-point.php?q=/u/e/im.100 и посмотри /u/e/msgid. В сущности, перенести на /u дело несложное и очень быстрое.

Я с /u/ разобрался =)

>Как оно будет с методом /x/? И когда появится на серверах? Ну, чтобы знать, когда перестанет все работать

Информация о разработке всегда сливается сюда, /x, я надеюсь, далеко не сразу отменит /u. Достаточно вспомнить что в масштабах существования проекта /m и /e существуют до сих пор и пока что поддерживаются нашими нодами.

> Удобно, но не очень логично, а я не люблю, когда нелогично. Поясню: /u/e/name/name/name... - где namespace, где метод, где параметры, сколько параметров? Всё в кучу.
Как раз таки всё логично: namespace - u, метод - e, параметры - name, а их количество нода сама считает. Тем более, порядок у всего этого одинаковый, а смена разделителя абсолютно ничего не решит.

>Пришлось проснуться и ответить...

Да ладно, пока и без этого есть, чем заняться.

>> Методы /list.txt и /blacklist.txt не являются частью стандарта, нигде не описаны и вообще.
>> Теперь они являются устаревшими и будут возвращать 'deprecated'.
>Это не методы, это внутренние файлы ноды, их вообще не надо показывать наружу, поэтому убирай (и можно даже без депрекатед).

Это какбы файлы. По крайней мере, /list.txt

>> Также устаревшими являются методы /e и /m, со временем они будут убраны.
>/e убирай, так как оно практически дублирует поведение /u/e, а вот /m убирать не надо, так как оно полезно для отладки.

OK, /m оставим.

>> Неймспейс /u пока под вопросом. Если оставлять обратную совместимость с существующими клиентами, то его придется оставить неизменным и делать новый, например /x.
>Не надо убирать! Если нужно новые функции, то лучше добавить их в /x

>> В обновленном API разделителем списков будет '+', немного изменится интерфейс
>Ну почему плюс? Со слешем же всё нормально было, зачем переусложнять?

С точки зрения кода вообще пофиг, какой разделитель.
Мне не нравится слэш, потому то по задумке и RFC это разделитель для обозначения иерархии объектов в урле. Т.е. то, что слева от слэша стоит по иерархии выше, чем то, что справа. Плюс же -- общепринятый разделитель равноправных объектов в урле.

>> Что касается ротации, всё чуть сложнее, чем кажется, но реализуется довольно просто.
>С ротацией разберёмся позже, сейчас усложнять стандарт не надо.

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

>И да, почему вдруг стандарты так быстро меняются? А спросить, нужно или не нужно? А сообщество наше?

Стандартом является то, что описано в официальной документации, остальное -- предложения.

>>Неймспейс /u пока под вопросом. Если оставлять обратную совместимость с существующими клиентами, то его придется оставить неизменным и делать новый, например /x.
>Я считаю что надо оставлять /u до последнего. Чтобы не пришлось в спешном порядке менять софт на узлах и на станциях поинтов. В конце концов это не столь обременительно.

Мне тоже ближе эволюционный метод, поэтому на /u пока никто не посягает.

>>В обновленном API разделителем списков будет '+', немного изменится интерфейс, будет добавлен метод для получения timestamp'а эхи.
>Вот это хорошо. Теперь можно будет не дёргать зазря списки и не выстраивать пустые diff'ы при каждом обмене. Одобрямс =)

Таймстемпы будут на серверах, когда мы утрясём API и оно будет везде реализовано.
Некоторым не нравится длинное имя метода /x/mtime и есть вариант сделать просто /x/t. Более того, оно в /x, а не в /u, поскольку не входит в изначальный протокол и является по сути необязательным расширением.

+ пока тоже на обсуждении. У Виктора есть возражения.

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

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

Речь идет о идее ротации, которую я предложил, она тут многим понравилась, но она довольно революционна для местного сообщества и требует некоторых изменений в механизме обмена и хранения, т.е. в самой сути ii. Это попытка уйти от ручного управления постфиксами без необходимости (поинтам) вытягивать весь архив целиком.

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

>Таймстемпы будут на серверах, когда мы утрясём API и оно будет везде реализовано.
>Некоторым не нравится длинное имя метода /x/mtime и есть вариант сделать просто /x/t. Более того, оно в /x, а не в /u, поскольку не входит в изначальный протокол и является по сути необязательным расширением.

Ну всё что не входит в стандартный /u и следует выносить это да. Насчёт длинного имени метода я поддерживаю некоторых. Единообразие ибо =)

>+ пока тоже на обсуждении. У Виктора есть возражения.

Так как мы присобачиваемся к http, то действительно хорошо бы его стандарты и традиции собдлюдать в форматах. Я за "+", если что. Хотя, логичнее было бы провести голосование.

>Речь идет о идее ротации, которую я предложил, она тут многим понравилась, но она довольно революционна для местного сообщества и требует некоторых изменений в механизме обмена и хранения, т.е. в самой сути ii. Это попытка уйти от ручного управления постфиксами без необходимости (поинтам) вытягивать весь архив целиком.

А. Но как бы там ни было, меня больше смущает текущая база. Когда-нибудь мы всё таки упрёмся в возможности ФС и работа с базой сообщений будет ох какой неторопливой. Конечно, никто не мешает завести архивную ноду и перенести старые эхи туда, но это решение ли это? Я уже второй день думаю над этим вопросом и пока что решения смены базы и архивных узлов перебарывают друг друга с загадочной периодичностью.

P.S.: Пока писал, решение с архивными нодами победило в очередной раз (Роман завещал нам блюсти простоту технологии =). Только скрипт надо написать.

P.P.S.: Оглядываясь на FIDOnet и вообще FTN, хочется вспомнить что там были разные форматы баз. Может, нам следует подумать и в этом направлении. Главное - оставить суть обмена, тоссинга, бандлов и всего прочего, связанного с передачей данных, максимально простым.

Ну и P.P.P.S.: Всё равно я бесполезен пока пишу свой клиент. А ведь я ещё и эхокоординатор, оказывается =)

>Так как мы присобачиваемся к http, то действительно хорошо бы его стандарты и традиции собдлюдать в форматах. Я за "+", если что. Хотя, логичнее было бы провести голосование.

Я веду статистику :)
Из разработчиков Виктор против, мы с тобой за, Дифрекс не высказался.

>А. Но как бы там ни было, меня больше смущает текущая база. Когда-нибудь мы всё таки упрёмся в возможности ФС и работа с базой сообщений будет ох какой неторопливой. Конечно, никто не мешает завести архивную ноду и перенести старые эхи туда, но это решение ли это? Я уже второй день думаю над этим вопросом и пока что решения смены базы и архивных узлов перебарывают друг друга с загадочной периодичностью.

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

Меня как раз больше всего напрягает геморрой с постфиксами. Текущее решение формой подозрительно напоминает костыль.

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

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

Но в идеале, я хочу сделать реализацию, при которой база бы осталась на уровне текстовых файлов, но при этом в один файл складировалось достаточно большое количество сообщений. Только без аутбаунда я пока не представляю как это заставить работать быстро. Но со временем что-нибудь придумаю, наверное. Правда в php я не особо. Только http://instead-games.ru намаслал, но это стоило очень больших усилий и даже небольших срачей в instead@conference.jabber.ru =)

>Я веду статистику :)
>Из разработчиков Виктор против, мы с тобой за, Дифрекс не высказался.

Я высказывался, что слэши в качестве разделителя меня не очень прут. :)

> С одной стороны у нас есть постфиксы (в принципе, это было бы не страшно, если бы не приходилось поинтам менять конфиг при перекатывании). С другой -- пухнущая база, которая рано или поздно приведёт к тормозам на стороне ноды

Никто не запрещает хранить сообщения в SQL/NoSQL СУБД.
ii это по сути протокол обмена, а как именно ты хранишь данные это не имеет значения.

>Никто не запрещает хранить сообщения в SQL/NoSQL СУБД.
>ii это по сути протокол обмена, а как именно ты хранишь данные это не имеет значения.

Ну обратного я и не утверждал. Но прикручивать СУБД это оверхед.

Можно сделать фичу, как у иксов (если мне не изменяет память) - позволять клиенту запрашивать список доступный "возможностей" через некий протокол расширений, который отдает, собственно, список фич (+ можно поддерживать версионность, аля DirectX - какую версию запросишь, с той и будешь работать, нужно это для того, чтобы если клиент делает какие-то поправочные действия все не полетело при обновлении расширения со стороны ноды.).

Да, это "слегка" усложняет устройство клиента и поднимает его интеллектуальный уровень на +1, но зато клиент будет спокойно работать с теми фичами, с которыми он умеет (или вообще не будет с ними работать, используя старый добрый /u).

Самое главное, чтобы это все происходило через отдельный запрос (допустим /x, от extensions), и никоим образом не влезало в основной протокол обмена. Это именно расширения, клиенты должны уметь работать и без них.

>>Я веду статистику :)
>>Из разработчиков Виктор против, мы с тобой за, Дифрекс не высказался.
>Я высказывался, что слэши в качестве разделителя меня не очень прут. :)

Оу. Извини, иногда тут непросто что-то отслеживать.
Итого, 3 за и 1 против.

>>Никто не запрещает хранить сообщения в SQL/NoSQL СУБД.
>>ii это по сути протокол обмена, а как именно ты хранишь данные это не имеет значения.
>Ну обратного я и не утверждал. Но прикручивать СУБД это оверхед.

Можно сериализовать средствами языка (или сторонними). Эхи сериализуются в лоб, сообщения кусками с индексом.

>Можно сериализовать средствами языка (или сторонними). Эхи сериализуются в лоб, сообщения кусками с индексом.

Подожду Виктора. Вот допишу свой клиент, может и за ноду возьмусь. Меня никак не покидает затея с нодой на лиспе =)

> Я считаю что надо оставлять /u до последнего. Чтобы не пришлось в спешном порядке менять софт на узлах и на станциях поинтов. В конце концов это не столь обременительно.
Поддерживаю.

> Таймстемпы будут на серверах, когда мы утрясём API и оно будет везде реализовано.
> Некоторым не нравится длинное имя метода /x/mtime и есть вариант сделать просто /x/t. Более того, оно в /x, а не в /u, поскольку не входит в изначальный протокол и является по сути необязательным расширением.
Не принципиально опять же, но лучше покороче, т.е. /x/t

> + пока тоже на обсуждении. У Виктора есть возражения.
+ принципиально ничего не меняет, по сравнению с тем же слешем, кроме следования формату RFC. Но совместимость сразу пропадёт, поэтому толку особого и нет.

> Ну и P.P.P.S.: Всё равно я бесполезен пока пишу свой клиент. А ведь я ещё и эхокоординатор, оказывается =)
Эхокоординатору положено следить за контентом, поэтому можно просто пару новых эх добавить и что-нибудь туда написать интересного =)

> Итого, 3 за и 1 против.
Ок, соглашаюсь, всё равно проголосовали уже :) Но менять разделитель лучше в последнюю очередь, чтобы совместимость не страдала.

>Но менять разделитель лучше в последнюю очередь, чтобы совместимость не страдала.

Насколько я понял, "+" в качестве разделителя будет в /x. Так что никто ничего ломать не собирается.

> Насколько я понял, "+" в качестве разделителя будет в /x. Так что никто ничего ломать не собирается.
Ну если в /x, то тогда всё нормально.

>Оффтопик. Я начинаю присматриваться к идее с уровнем пробелами, но пока сомневаюсь. При большом уровне вложенности/ответов от темы ничего кроме пробелов не останется.

Я от идеи деревьев отказался, остановился просто на тредах.

> Но прикручивать СУБД это оверхед.

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

Но кому надо - тот прикрутит субд, заморачиваться над этим не стоит, я считаю. Надо пилить протокол, конкретные реализации - дело третье.