о, я уже могу подписываться через веб-интерфейс


а, это... есть ли аналог ?n=1, чтобы можно было скормить один раз список для фетчера, и он потом выгребал все эхи, которые анонсированы.

> а, это... есть ли аналог ?n=1, чтобы можно было скормить один раз список для фетчера, и он потом выгребал все эхи, которые анонсированы.
Нет, потому что обычного эхолиста хватает. Фетчер может просто отсеять количество сообщений и описание.

фетчером может быть и обычный wget-curl :) получение raw-списка - это, по-моему, самая очевидная задача, зачем заставлять это делать других, когда это реализуется примитивно...

> фетчером может быть и обычный wget-curl :) получение raw-списка - это, по-моему, самая очевидная задача, зачем заставлять это делать других, когда это реализуется примитивно...

Как говорил Роман раньше: ну зачем всё переусложнять? =) И так уже куча стандартов и нестандартов. Фетчер - это штука, которая должна настраиваться вручную, и ничего в этом плохого нет.

modus operandi у меня всегда был один.

это не усложнение, это упрощение всей схемы.

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

> а реализация в стандартной ноде заняла ровно две строки.
Я понимаю, что это всего 2 строки. Но зачем плодить всякие стандарты лишние? Если нужен список эх, бери list.txt или /x/echolist, если нужны только названия эх, то отсекаем лишнее содержимое. Какие проблемы?

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

> Какие проблемы?

Проблемы две. Целостность и практичность. Концепция должна отвечать настоящим и будущим требованиям. Фичи, которые упрощают жизнь и реализацию - нужны. Которые только плодят потенциальные проблемы - не нужны.

В этом и состоит искусство, называемое "творчество". Определять, что оставлять, а что отсекать. Вещь нужна прежде всего не для того, чтобы её делать, а для того, чтобы ею пользоваться. Проще одному внести одну маленькую правку, чем потом КАЖДОМУ, кто захочет это реализовать, делать какие-то манипуляции...

> Вот и я по то же. Кому сейчас нужен фетчер с автоподпиской на bash?

мне. чтобы решать какие-то задачи in-place

> Если людям нужно, то это реализуется. Что-то я пока не вижу здесь толпы bash-скриптеров, которым лень освоить coreutils

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

> Стандарты, у нас, по крайней мере, решаются голосованием.

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

> Всего лишь вызов какого-нибудь sed или cut добавить...

После "делаю дифф на два rss файла" я уже вообще ничему не удивляюсь.

>это упростит мне обмен с вашей нодой.

Ну так что ж теперь. Github, php и пул-реквест никто не запрещал.

>потому что у меня по такому стандарту уже многое обменивается, и я не понимаю, почему одни сайты надо опрашивать так, а другие - иначе.

Ну ты сам сказал что тебе плевать как оно. И в своё время сказал что у тебя свой путь. И постоянно подчёркиваешь что мы сепаратисты. Мы опрашиваем всё единообразно. Твои реализации -- это твои реализации. И это твоё решение. А могли бы вместе развиваться.

А вообще, не проще было бы сделать это на стороне фетчера из list.txt? Или ты это из экономии трафика сделал? Правда интересно.

> Ну ты сам сказал что тебе плевать как оно.

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


> А вообще, не проще было бы сделать это на стороне фетчера из list.txt?

Однозначные решения отличаются от неоднозначных решений тем, что они однозначны :) И легко воспроизводимы, например, фетчер, выкачивающий всё, пишется минуты за 2, даже не включая голову и не концентрируюясь на задаче, чисто механически - тут нет никаких нюансов, всё линейно:

mkdir echo
mkdir msg

curl http://51t.ru/list.txt?n=1 > list.txt

for n in `cat list.txt`
do
curl http://51t.ru/e/$n > echo/$n
for f in `cat echo/$n`
do
curl http://51t.ru/m/$f > msg/$f
done
done

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


> А могли бы вместе развиваться.

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

Если кто хочет, может посмотреть исходные сообщения. Ровно всё, что там задумано, исполняется, и исполняется так, что жалеть об этом не приходится. У меня единая и целая концепция, где вот тут потрясёшь - и вон там, в будущем, уши вылезут. Уже не раз радовался тому, что изначально принимал верные решения, и что некоторые задачи оказалось легко решать (в отличие от того варианта, который предлагали на лорах, как "более правильный идеологически"). Поэтому я не хочу экспериментировать "где что может отвалиться" и кидаться в крайности "то мне всё, то мне ничего". Цель - завоевать мир, сделать ii массовым стандартом, потихоньку, шаг за шагом. И именно это я и буду делать - помогать этому миру стать лучше. А не по 50 раз объяснять, почему некоторые вещи уже были опробованы на практике двадцать лет назад, и доказали либо свою полную бесполезность, либо практичность...

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

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


> Ну так что ж теперь. Github, php и пул-реквест никто не запрещал.

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

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

>Мне непонятно, зачем всех владельцев клиентов, фечеров и всех остальных заставлять решать проблему уже другого класса, где присутствует анализ. для кого-то когда-то в стороннем чём-то это может быть причиной между "реализовать где-то прямо сейчас" и "не реализовывать прямо сейчас". Большинству людей неинтересно ковыряться. и если задача решается легко и "сама", без трудностей - он её решает. если не решается - не решает. И если проблема решается изнутри двумя строчками - то это верный путь.

Ну ведь нода уже отдаёт то, чем хочет делиться. list.txt же это оно? Просто не совсем понял зачем плодить две схожие сущности. Какая разница взять list.txt и из него первый столбец или то что ты предлагаешь? Или кинь в меня каким-нить уже готовым разъяснением чтоб не объяснять мне тугодуму всё в 50-й раз. Я пока просто не понял разницы между n=1 и list.txt с точки зрения передачи данных.

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

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

>В фидо станционность была связана именно с особенностями телефоных станций тех времён, сложностями межгорода и подобным. В интернете выбор станции - это выбор строки адреса в url, безо всяких на то проблем.

Вообще, да. Но интернет -- не гарант доступности станции. Бывают косяки у провайдеров, бывают у хостеров, бывают у магистральщиков. Дума старательно запрещает интернет как может. Если придётся возвращаться на те же телефоны или что-либо такое же дорогое в плане доступа до тебя, то моя станция как-нить худо-бедно даст мне общения =) С часом почты даже если.

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

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

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

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

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

PHP-нода это была и есть возможность поднять ноду на стрёмных хостингах. Жаль что теперь они сильно разные.

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

> Ну ведь нода уже отдаёт то, чем хочет делиться. list.txt же это оно? Просто не совсем понял зачем плодить две схожие сущности.

у list.txt есть несколько опций вывода. нужно это, чтобы не делать лишнее на клиенте.

> Пока технари ничего не наворотили, насколько мне известно.

До революции было по 10 человек пишущих ежедневно, разные обсуждения, картинки рисовали, игры придумали. Иногда, чтобы сломать, достаточно просто ничего не делать :)

> Вообще, да. Но интернет -- не гарант доступности станции. Бывают косяки у провайдеров, бывают у хостеров, бывают у магистральщиков. Дума старательно запрещает интернет как может. Если придётся возвращаться на те же телефоны или что-либо такое же дорогое в плане доступа до тебя, то моя станция как-нить худо-бедно даст мне общения =)

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

> Плодить станции это есть неплохо.

И у каждой свой несовместимый стандарт. Поэтому писатели клиентов ориентируются только на один стандарт - который им ближе, лично мой клиент умеет только мою станцию. А андроид клиент мою станцию категорически не умеет, в отличие от php-станции, хотя разницы я вообще в упор не вижу (кстати, почему андроид-клиент вначале запрашивает имя эхи, как /u/m/ЭХА/MSGID/MSGID?)

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

Изначально смысл был в том, чтобы сделать простой, практичный, ЕДИНЫЙ стандарт, который можно было просто, легко и весело реализовывать на чём угодно, и работал бы он везде одинаково. Поэтому и был переезд с /z/ на /u/, как на более универсальный и простой в воспроизведении. А когда люди не смотрят в будущее, а хотят ограничиться только своей реализацией (впрочем, они именно так и говорят, хотим себе, а люди не нужны :) - это не развитие. Это какое-то создание чего-то для себя и только для себя, но с непонятными целями.

> Я вообще не понимаю этого раскольничества.

Я тоже.

> Я просто на тебя обиделся в тот эпохальный обмен матами и тут остался =) А вообще, мне твои идеи как раз ближе.

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

Такие вещи выясняютя на практике. Потому что непонятно, как это будет работать. Это просто расширение уже используемого list.txt (с учётом того, что его использовать начали ещё до того, как я дал отмашку "тут всё сформировано, пляшем, девки, с list.txt", поэтому "так сложилось исторически")

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

Самая главная вещь - это концепция. С её помощью можно померить всё :)

>мне. чтобы решать какие-то задачи in-place
Для тебя сделать можно. И совсем не сложно. Но чтобы это стало стандартом, надо, чтобы оно стало действительно необходимо.

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

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

>После "делаю дифф на два rss файла" я уже вообще ничему не удивляюсь
Дифф на 2 рсс файла - это громко сказано :) На самом деле там проще гораздо. см. исходники.

> Тогда почему ты за них переживаешь?

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

> Я сделаю, конечно, но чтобы это стало стандартом, это должен требовать не один человек

Сеть сделал один человек. Его об этом никто не просил. И все стандарты утвердил тоже один человек. Который просто делает сеть, и ничего больше. Некоторые вещи просто обозначены заранее, в том числе ...

> Разве list.txt для гейтования предназначен?

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

> Тем более, туда и локалки вписывать можно.

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

> Дифф на 2 рсс файла - это громко сказано :) На самом деле там проще гораздо. см. исходники.

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

>> Тем более, туда и локалки вписывать можно.

>значит, надо будет предосмотреть механизм исключения в фетчере...

Но это усложнение клиента. Надо подумать как это сделать на стороне ноды. Потому как в моём списке есть и spline.local.14.

клиенту это не нужно, он подписывается.

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

Я сейчас хочу попробовать ещё парой строк на ноде при &n=1 скрытые эхи не отображать. Или не стоит этим заниматься?

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

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