Обновился на новую версию ii-php, прописал эхолист. Теперь клиентописателям можно спокойно проводить эксперименты с экономией трафика, автоподписками, описаниями эх.

>автоподписками

Давно хотел спросить как это планируется делать. Да всё руки не доходили. Пока кроме сообщения с особым сабжем и ссылкой на новую версию эхи ничего не придумал. Так как это будет?

>> автоподписками
> Давно хотел спросить как это планируется делать. Да всё руки не доходили. Пока кроме сообщения с особым сабжем и ссылкой на новую версию эхи ничего не придумал. Так как это будет?

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

Если ты насчёт переполнения эх, то лично я предполагаю, что это можно сделать с помощью сообщения специальным поинтом, например, "subscribe-bot". Нода проверяет, сколько сообщений в эхе, и если их количество превышает лимит, то она даёт сообщение указанным поинтом с именем новой эхи, чтобы клиенты автоматически переподписывались. Либо просто перемещает сообщения из одной эхи в другую, как предложил gadfly.

>Я имел в виду автоподписку по списку эх. Ну вот запускает первый раз человек клиент, прописывает адрес ноды, а какие там есть эхи - не знает. Клиент автоматически подгружает, что есть на станции.

Монструзно. Клиент тут же утягивает все болталки за все года. Надо идти по пути диалог-клиента =) Рома уже сделал. Подписка производится прямо в клиенте. Указываешь линк для подключения и получаешь список эх, расскавляешь галочки на что хочешь получаться и радуешься.

> Монструзно. Клиент тут же утягивает все болталки за все года. Надо идти по пути диалог-клиента =) Рома уже сделал. Подписка производится прямо в клиенте. Указываешь линк для подключения и получаешь список эх, расскавляешь галочки на что хочешь получаться и радуешься.

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

>Указываешь линк для подключения и получаешь список эх, расскавляешь галочки на что хочешь получаться и радуешься.

Осталось только чтобы ноды имели общий механизм отдачи списка эх

>Осталось только чтобы ноды имели общий механизм отдачи списка эх

/list.txt

Пока &h и &el я не сделал, но просто /list.txt пашет и у меня и у Виктора. И у Ромы, наверняка.

> /list.txt
Давайте тогда list.txt за стандарт возьмём. У меня просто он ещё дублируется на /x/echolist, но поскольку первоначальный вариант много где работает, я не против. Кто против - тот пусть выскажется.

> Пока &h и &el я не сделал

&h и &el дублирует /x/t. Тем более, это реализовано костыльно, в виде отдельных кусков данных, а не как схема параметров. Поэтому насчёт такого я против.

как раз только об этом в I'm спросил.
относительный путь одинаковый на всех нодах?

> относительный путь одинаковый на всех нодах?
Это либо http://51t.ru/list.txt в случае python-ноды, либо http://irk38.tk/ii/ii-point.php?q=/list.txt в случае php ноды. Относительно /u/ он одинаков, но советую лучше брать за основу не /u/, а /, чтобы было проще пользоваться расширениями

ну как же он одинаков, если в одном случае ../list, а в другом /list

> ну как же он одинаков, если в одном случае ../list, а в другом /list
Ты точки имеешь в виду? Ну да, в python ноде есть редирект по точкам, а на php ноде нет. Я предлагаю либо отсекать 2 последних символа с /u/ (правда, это костыль), либо сразу брать адрес без /u/, то есть просто /

/u/ - это схема. как http: в http. это показывает, что это именно ii нода (и именно метод /u/), а не продуктовый магазин. поэтому ничего страшного в обрезании /u/ - нету.

Ну и ладно. Всё равно клиент не я реализую, пусть он решает. Принципиально ничего особенного.

У вас разные пути.
Нужен один для всех нод.

Чтобы если использовать клиент на другой ноде, можно было конкатенацией nodeUrl и /list.txt получить список эх.

Вроде разобрались

Я наоборот говорил о том, что нужен единый относительный путь. Если у всех нод он ../ list.txt, вопрос снимается

> Я наоборот говорил о том, что нужен единый относительный путь. Если у всех нод он ../ list.txt, вопрос снимается
Зачем брать относительный путь, если можно обойтись абсолютным? В некоторых клиентах и во многих фетчерах так и делается.

>Зачем брать относительный путь, если можно обойтись абсолютным? В некоторых клиентах и во многих фетчерах так и делается.

Затем, чтобы клиент работал со всеми нодами. посмотри свой пример ниже, если ты к адресу /u/ каким-то образом добавишь list.txt получится путь, который будет валидным на обеих нодах. "Добавить" не обязательно означает, что надо сложить строки.

> Затем, чтобы клиент работал со всеми нодами.
Я уже рассказал, как сделать так, чтобы клиент работал со всеми нодами.

> посмотри свой пример ниже, если ты к адресу /u/ каким-то образом добавишь list.txt получится путь, который будет валидным на обеих нодах. "Добавить" не обязательно означает, что надо сложить строки.
Ты мне скажи, как ты предлагаешь это сделать? При этом так, чтобы не нарушались стандарты, и получалось работать со всеми нодами одновременно. Я свои варианты уже озвучил.

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

Да так как есть сейчас и оставить. Если вы договорились, что лист доступен по адресу на уровень выше чем /u/, то все ОК.

ОК. Если будет работать - значит хорошо :)

Вроде работает