[>]
Re: офлайнизатор
im.100
vit01(mira, 1) — 51t
2014-07-28 19:19:46
Хм, чтобы набрать контента... Тогда это, получается, так и реализуется, как обычные эхи. Просто на такой ноде может не быть поинтов, а забор ведётся клиентом, который может сохранять и экспортировать сообщения выборочно. Так?
[>]
Re: list.txt
im.100
vit01(mira, 1) — 51t
2014-07-28 19:24:42
> а реализация в стандартной ноде заняла ровно две строки.
Я понимаю, что это всего 2 строки. Но зачем плодить всякие стандарты лишние? Если нужен список эх, бери list.txt или /x/echolist, если нужны только названия эх, то отсекаем лишнее содержимое. Какие проблемы?
> к тому же, это уже используется в разных фетчерах разных поколений на разных компьютерах.
Это не аргумент. Тем более, у нас не используется. При сильной необходимости - см. выше.
[>]
Re: офлайнизатор
im.100
51t(mira, 2) — vit01
2014-07-28 19:28:20
Свободного контента можно сотни мегабайт офлайнизировать, в тысячи эх. Оно не нужно средь обычных эх, будет только путаться.
Гейтования им тоже не нужно... можно вообще просто завести отдельный клиент, подключиться к отдельному сайту, натыкать там галочек на нужное, сохранить, и читать офлайн. Впрочем, клиентом может быть что угодно, вплоть до стороннего веб-сайта. Короче говоря, ii это xml(rdf, и всё подобное) для бедных и девочек, будущий стандарт всегобщего обмена ;), устойчивый к массовому гейтованию :)
в этом случае ii именно формат получения текста для офлайна (вообще, у меня на стандарты ii большие планы)
[>]
Re: list.txt
im.100
51t(mira, 2) — vit01
2014-07-28 19:31:46
> Какие проблемы?
Проблемы две. Целостность и практичность. Концепция должна отвечать настоящим и будущим требованиям. Фичи, которые упрощают жизнь и реализацию - нужны. Которые только плодят потенциальные проблемы - не нужны.
В этом и состоит искусство, называемое "творчество". Определять, что оставлять, а что отсекать. Вещь нужна прежде всего не для того, чтобы её делать, а для того, чтобы ею пользоваться. Проще одному внести одну маленькую правку, чем потом КАЖДОМУ, кто захочет это реализовать, делать какие-то манипуляции...
[>]
Re: офлайнизатор
im.100
vit01(mira, 1) — 51t
2014-07-28 19:33:21
Значит я всё-таки понял, что ты имеешь в виду. Реализуется сие в пару строчек. Подобную ноду поднять - тоже не проблема. Нужен только контент.
[>]
Re: офлайнизатор
im.100
51t(mira, 2) — vit01
2014-07-28 19:35:49
Реализация этого - в 0 строчек.
Самое главное - это удобная подача и удобная категоризация информации... а также эта самая информация. Ну и некоторые вещи по инфраструктуре.
[>]
Re: офлайнизатор
im.100
spline(station13, 1) — 51t
2014-07-28 19:37:32
Посмотрим как оно будет. Жаль что нельзя будет просто выбрать нужное. Да и ни к чему это в ii, конечно. Надо смотреть как оно будет =)
[>]
Re: офлайнизатор
im.100
spline(station13, 1) — 51t
2014-07-28 19:44:46
В идеале это надо просто немного усложнить клиент чтобы он по линкам (в совсем сферическом случае по базе линков) забирал нужные эхи. Или я не так тебя понял?
[>]
Re: list.txt
im.100
vit01(mira, 1) — 51t
2014-07-28 19:45:10
> Вещь нужна прежде всего не для того, чтобы её делать, а для того, чтобы ею пользоваться.
Вот и я по то же. Кому сейчас нужен фетчер с автоподпиской на bash? Тем более, для этого потребуется не так много манипуляций. Всего лишь вызов какого-нибудь sed или cut добавить...
> Проще одному внести одну маленькую правку, чем потом КАЖДОМУ, кто захочет это реализовать, делать какие-то манипуляции...
Стандарты, у нас, по крайней мере, решаются голосованием. Если людям нужно, то это реализуется. Что-то я пока не вижу здесь толпы bash-скриптеров, которым лень освоить coreutils, и которые нуждаются в подробной штуке.
[>]
Re: list.txt
im.100
51t(mira, 2) — vit01
2014-07-28 19:56:05
> Вот и я по то же. Кому сейчас нужен фетчер с автоподпиской на bash?
мне. чтобы решать какие-то задачи in-place
> Если людям нужно, то это реализуется. Что-то я пока не вижу здесь толпы bash-скриптеров, которым лень освоить coreutils
это упростит мне обмен с вашей нодой. потому что у меня по такому стандарту уже многое обменивается, и я не понимаю, почему одни сайты надо опрашивать так, а другие - иначе.
> Стандарты, у нас, по крайней мере, решаются голосованием.
меня не интересуют ваши стандарты, мне уже всё равно понятно, как вы понимаете проблемы реальных людей, и те возможности ii, которые могут быть, а могут и не быть. я же исхожу из всего опыта, который получен в fido, git, и многого другого, и тем, как люди это используют или не используют. впрочем, всё равно вам что-то бесполезно объяснять... просто у меня подобная вещь была, разумеется, запланирована изначально...
> Всего лишь вызов какого-нибудь sed или cut добавить...
После "делаю дифф на два rss файла" я уже вообще ничему не удивляюсь.
[>]
Re: офлайнизатор
im.100
51t(mira, 2) — spline
2014-07-28 19:59:56
> Посмотрим как оно будет. Жаль что нельзя будет просто выбрать нужное. Да и ни к чему это в ii, конечно. Надо смотреть как оно будет =)
не понял вопроса...
вот сейчас я захожу, смотрю эхи, типа
off.nz.14
off.mirra.lohvickaya.14
и так далее.
натыкиваю нужное на подписку
загружаюсь
грызу кабель интернета
сижу, читаю :)
как-то вот так.
по одному сообщению - ну, по одному сообщению можно и вручную скачать, смысл таких "пакетных наборов" - именно в пакете. Это как газета, или даже "роман-газета", такой отобранный редакторами набор, который, потенциально, будет весь интересен читателю. кому не нужен офлайн - тому это вообще не особо нужно.
[>]
Re: list.txt
im.100
spline(station13, 1) — 51t
2014-07-28 20:09:14
>это упростит мне обмен с вашей нодой.
Ну так что ж теперь. Github, php и пул-реквест никто не запрещал.
>потому что у меня по такому стандарту уже многое обменивается, и я не понимаю, почему одни сайты надо опрашивать так, а другие - иначе.
Ну ты сам сказал что тебе плевать как оно. И в своё время сказал что у тебя свой путь. И постоянно подчёркиваешь что мы сепаратисты. Мы опрашиваем всё единообразно. Твои реализации -- это твои реализации. И это твоё решение. А могли бы вместе развиваться.
А вообще, не проще было бы сделать это на стороне фетчера из list.txt? Или ты это из экономии трафика сделал? Правда интересно.
[>]
Re: офлайнизатор
im.100
spline(station13, 1) — 51t
2014-07-28 20:22:50
Понял. Просто не был уверен что полностью. А настройку на разные сервера прямо в клиенте сделаешь? Или как это будет выглядеть? Я пока просто слабо представляю =(
[>]
Re: list.txt
im.100
51t(mira, 2) — spline
2014-07-28 21:10:55
> Ну ты сам сказал что тебе плевать как оно.
Я гейтуюсь с этой нодой. И, вместо того, чтобы сделать так, как у меня сделано везде, мне нужно будет придумывать новый формат, и следить за всеми фетчерами, чтобы они его поддерживали... или постоянно прописывать эхи вручную.
> А вообще, не проще было бы сделать это на стороне фетчера из 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-ноды изначально задумывались только с одной определённой целью, потому что именно куча самостоятельных серверов уже создаёт проблемы нормальной работе развивающихся клиентов. Вместо гармоничного развития, когда всё растёт из единого стандарта, появилось куча всего... и без прозрачной совместимости. Это проблема, которую я изначально хотел избежать, потому что мне понятны последствия этого (проблема с андроид-клиентом частично связана и с этим). А ты мне предлагаешь участвовать в этом :) Смешно.
Если бы оно развивалось так, как планировалось изначально - конечно, было бы намного лучше. Но получилось так, как получилось, будем исходить из реалий. Но если вы вообще не собираетесь практичность обеспечивать, то мне совсем непонятно, что вы вообще хотите...
[>]
Re: офлайнизатор
im.100
51t(mira, 2) — spline
2014-07-28 21:14:11
клиент уже умеет несколько серверов.
получать через via, отправлять через sendvia... к сожалению, там несколько кривовато, но это именно в рассчёте на загрузку в основном эх для чтения с других источников. например
via 51t.ru ii.14 im.1407
im.14.sendvia authstr@51t.ru
ii.1407.sendvia authstr@51t.ru
пока так работает...
[>]
Re: list.txt
im.100
spline(station13, 1) — 51t
2014-07-28 22:08:10
>Мне непонятно, зачем всех владельцев клиентов, фечеров и всех остальных заставлять решать проблему уже другого класса, где присутствует анализ. для кого-то когда-то в стороннем чём-то это может быть причиной между "реализовать где-то прямо сейчас" и "не реализовывать прямо сейчас". Большинству людей неинтересно ковыряться. и если задача решается легко и "сама", без трудностей - он её решает. если не решается - не решает. И если проблема решается изнутри двумя строчками - то это верный путь.
Ну ведь нода уже отдаёт то, чем хочет делиться. list.txt же это оно? Просто не совсем понял зачем плодить две схожие сущности. Какая разница взять list.txt и из него первый столбец или то что ты предлагаешь? Или кинь в меня каким-нить уже готовым разъяснением чтоб не объяснять мне тугодуму всё в 50-й раз. Я пока просто не понял разницы между n=1 и list.txt с точки зрения передачи данных.
>Не могли бы. Технари убивают любой социальный проект. Проверено неоднократно. Они видят данные, но не видят людей. Они мыслят бинарно, и поэтому заранее отсевают категоричным "не нужно" те категориями, с которыми если работать по их понятиям, можно получить много пользы.
Пока технари ничего не наворотили, насколько мне известно. Были идеи, обсуждения, но они ни к чему не привели.
>В фидо станционность была связана именно с особенностями телефоных станций тех времён, сложностями межгорода и подобным. В интернете выбор станции - это выбор строки адреса в url, безо всяких на то проблем.
Вообще, да. Но интернет -- не гарант доступности станции. Бывают косяки у провайдеров, бывают у хостеров, бывают у магистральщиков. Дума старательно запрещает интернет как может. Если придётся возвращаться на те же телефоны или что-либо такое же дорогое в плане доступа до тебя, то моя станция как-нить худо-бедно даст мне общения =) С часом почты даже если.
>Поэтому плодить станции - я в этом тоже не вижу вообще смысла, кроме увеличения задержки ответа с 0 секунд до десятков минут или даже часов.
Плодить станции это есть неплохо. Потому как есть вариант остаться ни с чем в случае с одной станцией. Мне приятно иметь распределённость, тем более что она подразумевалась ещё первыми стандартами. Ты же сам радовался что у нас есть несколько станций.
>Но лично я ни от кого не отделялся. Ваш эксперимент, конечно, любопытный, но смысла в нём я не вижу. Чем дальше смотрю, тем больше понимаю, что ii - это вообще не тот инструмент, и что он - для другого. И поэтому стремление всё поменять - от непонимания. Таким образом проблемы будут только множиться, и в итоге это перерастёт в неизвестно что, зато с ушами от ii. Проще тогда уж сразу определиться с целями, задачами, продумать внятную концепцию "как это будет работать, и как это будет работать плохо", и её реализовывать. А не пытаться изобрести "как ii, только не ii".
Я вообще не понимаю этого раскольничества. Я просто на тебя обиделся в тот эпохальный обмен матами и тут остался =) А вообще, мне твои идеи как раз ближе.
>php-ноды изначально задумывались только с одной определённой целью, потому что именно куча самостоятельных серверов уже создаёт проблемы нормальной работе развивающихся клиентов.
PHP-нода это была и есть возможность поднять ноду на стрёмных хостингах. Жаль что теперь они сильно разные.
[>]
Re: офлайнизатор
im.100
spline(station13, 1) — 51t
2014-07-28 22:28:46
>клиент уже умеет несколько серверов.
Ага. Спасибо за разъяснения.
Кстати, прикрутил /list.txt&n=1 себе на ноду. Хотя так и не понял чем это принципиально отличатся от первого столбца /list.txt. Но мне не тяжело.
Кстати, оно сразу же и на еретический /x/echolist заработало =)
[>]
Re: list.txt
im.100
ntrknlmp.exe(mira, 9) — 51t
2014-07-28 23:06:04
Поэтому нужен один четко документированный стандарт, который должен описывать протокол, а не реализацию.
[>]
Re: list.txt
im.100
51t(mira, 2) — spline
2014-07-29 04:24:12
> Ну ведь нода уже отдаёт то, чем хочет делиться. list.txt же это оно? Просто не совсем понял зачем плодить две схожие сущности.
у list.txt есть несколько опций вывода. нужно это, чтобы не делать лишнее на клиенте.
> Пока технари ничего не наворотили, насколько мне известно.
До революции было по 10 человек пишущих ежедневно, разные обсуждения, картинки рисовали, игры придумали. Иногда, чтобы сломать, достаточно просто ничего не делать :)
> Вообще, да. Но интернет -- не гарант доступности станции. Бывают косяки у провайдеров, бывают у хостеров, бывают у магистральщиков. Дума старательно запрещает интернет как может. Если придётся возвращаться на те же телефоны или что-либо такое же дорогое в плане доступа до тебя, то моя станция как-нить худо-бедно даст мне общения =)
То, что мы можем жить в каменном веке - не значит, что надо отбрасываться в каменный век. И уж тем более - изобретать несовместимые стандарты.
> Плодить станции это есть неплохо.
И у каждой свой несовместимый стандарт. Поэтому писатели клиентов ориентируются только на один стандарт - который им ближе, лично мой клиент умеет только мою станцию. А андроид клиент мою станцию категорически не умеет, в отличие от php-станции, хотя разницы я вообще в упор не вижу (кстати, почему андроид-клиент вначале запрашивает имя эхи, как /u/m/ЭХА/MSGID/MSGID?)
Поэтому, даже не оформив базовые понятия, уже побежали, задрав штаны, что-то навешивать. Причём то, что уже используется реально, "это ненужная фича", зато то, что будет работать непонять как (кстати, у меня сейчас практически во всех реализациях используются таймштампы эх - проблем с ними хватает. а то, чем можно реально отслеживать неизменность эх, вне зависимости от внешних факторов - давно есть в базовой реализации) - тащутъ в стандарт.
Изначально смысл был в том, чтобы сделать простой, практичный, ЕДИНЫЙ стандарт, который можно было просто, легко и весело реализовывать на чём угодно, и работал бы он везде одинаково. Поэтому и был переезд с /z/ на /u/, как на более универсальный и простой в воспроизведении. А когда люди не смотрят в будущее, а хотят ограничиться только своей реализацией (впрочем, они именно так и говорят, хотим себе, а люди не нужны :) - это не развитие. Это какое-то создание чего-то для себя и только для себя, но с непонятными целями.
> Я вообще не понимаю этого раскольничества.
Я тоже.
> Я просто на тебя обиделся в тот эпохальный обмен матами и тут остался =) А вообще, мне твои идеи как раз ближе.
У меня свои методы работы с молодёжью. Кроме того, это уже было после, когда надо было уже кардинально что-то решать.
[>]
Re: list.txt
im.100
51t(mira, 2) — ntrknlmp.exe
2014-07-29 04:28:37
Такие вещи выясняютя на практике. Потому что непонятно, как это будет работать. Это просто расширение уже используемого list.txt (с учётом того, что его использовать начали ещё до того, как я дал отмашку "тут всё сформировано, пляшем, девки, с list.txt", поэтому "так сложилось исторически")
А сейчас возможностей так мало и они настолько наглядны, что если что-то непонятно, самый авторитетный источник информации (по оригинальной ii) это "спросить меня" - делать огромную документацию в которой всё равно никто ничего не поймёт да и не будет читать - це не мой путь, поэтому если непонятно, лучше сразу спросить, а не пытаться домысливать... в любом случае, есть неоднозначные нюансы, которые понятны только на практике.
Самая главная вещь - это концепция. С её помощью можно померить всё :)
[>]
Re: list.txt
im.100
vit01(mira, 1) — 51t
2014-07-29 06:08:27
>мне. чтобы решать какие-то задачи in-place
Для тебя сделать можно. И совсем не сложно. Но чтобы это стало стандартом, надо, чтобы оно стало действительно необходимо.
>это упростит мне обмен с вашей нодой. потому что у меня по такому стандарту уже многое обменивается, и я не понимаю, почему одни сайты надо опрашивать так, а другие - иначе.
Разве list.txt для гейтования предназначен? Там же не все эхи, а только некоторые. Тем более, туда и локалки вписывать можно.
>меня не интересуют ваши стандарты
Тогда почему ты за них переживаешь? Я сделаю, конечно, но чтобы это стало стандартом, это должен требовать не один человек, во-первых, а во-вторых, должен внятно аргументировать. Не так, что "мне лень добавить пару строк к клиенту, пусть этим сервер займётся".
>После "делаю дифф на два rss файла" я уже вообще ничему не удивляюсь
Дифф на 2 рсс файла - это громко сказано :) На самом деле там проще гораздо. см. исходники.
[>]
Re: list.txt
im.100
51t(mira, 2) — vit01
2014-07-29 06:36:54
> Тогда почему ты за них переживаешь?
Я не переживаю, я гейтуюсь. Но я же не могу всерьёз воспринимать ваши подходы к практичности - они не добавляют удобства. Способ "простого списка", наоборот, добавляет удобство, и у меня используется везде.
> Я сделаю, конечно, но чтобы это стало стандартом, это должен требовать не один человек
Сеть сделал один человек. Его об этом никто не просил. И все стандарты утвердил тоже один человек. Который просто делает сеть, и ничего больше. Некоторые вещи просто обозначены заранее, в том числе ...
> Разве list.txt для гейтования предназначен?
list.txt предназначен для оповещения. использовать его для гейтования - это самый очевидный способ. чтобы знать, какие эхи есть на станции, и подписываться на них... иначе при наличии кучи нод будет непонятно, что, как и у кого гейтовать.
> Тем более, туда и локалки вписывать можно.
значит, надо будет предосмотреть механизм исключения в фетчере...
> Дифф на 2 рсс файла - это громко сказано :) На самом деле там проще гораздо. см. исходники.
Есть очевидный способ исключения дублей, который используют абсолютно все, в том числе - мой фетчер.
[>]
Re: офлайнизатор
im.100
51t(mira, 2) — spline
2014-07-29 06:40:04
Тогда давай с тобой гейтоваться, списками... захочешь загейтовать мою эху, просто пропишешь её в список, и будет ходить... правда, там есть некоторые нюансы, связанные с r, поэтому в локальный мейлер всё равно придётся прописывать, хотя и это я смогу, наверное, повесить на автоматику.
[>]
Re: list.txt
im.100
spline(station13, 1) — 51t
2014-07-29 06:45:25
>> Тем более, туда и локалки вписывать можно.
>значит, надо будет предосмотреть механизм исключения в фетчере...
Но это усложнение клиента. Надо подумать как это сделать на стороне ноды. Потому как в моём списке есть и spline.local.14.
[>]
Re: офлайнизатор
im.100
spline(station13, 1) — 51t
2014-07-29 07:07:25
>Тогда давай с тобой гейтоваться, списками... захочешь загейтовать мою эху, просто пропишешь её в список, и будет ходить... правда, там есть некоторые нюансы, связанные с r, поэтому в локальный мейлер всё равно придётся прописывать, хотя и это я смогу, наверное, повесить на автоматику.
Давай попробуем. Только я традиционно до 17:00 MSK серьёзно что-либо ворочать на стороне сервера не могу. Ну и надо ещё посмотреть на твой новый гейт.
Кстати, что за нюансы и что за "r"? А то я только одноимённый ЯП вспомнил, но это точно не он =)
Ну и это... Когда твой оффлайнизатор будет доступен? Хочется уже посмотреть.
[>]
To 51t
im.100
spline(station13, 1) — All
2014-07-29 07:10:27
И ещё это. Если не затруднит, то можешь составить описание протокола (желательно в двух частях: что есть и что будет в ближайшем будущем)? Потому как последнее что я помню, это было описание /u/, которое без практики понималось слабо, а сейчас уже есть фичи у тебя, о которых я узнаю случайно =)
[>]
Re: list.txt
im.100
51t(mira, 2) — spline
2014-07-29 07:11:53
клиенту это не нужно, он подписывается.
это для фетчера. а там "нужны все эхи, кроме одной-двух" - это вообще штатная ситуация. будет просто новое слово в конфиге... ждите build4 этим летом :)
[>]
Re: list.txt
im.100
spline(station13, 1) — 51t
2014-07-29 07:21:12
Я сейчас хочу попробовать ещё парой строк на ноде при &n=1 скрытые эхи не отображать. Или не стоит этим заниматься?
[>]
Re: list.txt
im.100
spline(station13, 1) — 51t
2014-07-29 07:29:31
>это для фетчера. а там "нужны все эхи, кроме одной-двух" - это вообще штатная ситуация. будет просто новое слово в конфиге... ждите build4 этим летом :)
В общем, сделал. Есть список "скрытых" эх, которые не попадают в сокращённый список, есть список эх и список архивных эх (это для веб-читалки). Последние два для list.txt склеиваются всегда, а "скрытые" приклеиваются если &n не определён. Не знаю насколько верно, но поставленную задачу решает. Хотя, я думаю, это и на стороне фетчера должно быть.
[>]
Re: To 51t
im.100
51t(mira, 2) — spline
2014-07-29 08:45:44
> И ещё это. Если не затруднит, то можешь составить описание протокола (желательно в двух частях: что есть и что будет в ближайшем будущем)?
да можно просто в hg поглядеть в run.py все роуты:
/blacklist.txt - это список чёрных сообщений эхи. может применяться, например, клиентом, чтобы удалить весь навалившийся на него спам, разом, по нажатию кнопки
/list.txt - вывод эх станции. опции:
?n=1 - краткий список
?h=1 - вместо описания выводятся hsh/хэшсумма, для проверки на изменения
?el=эха1/эха2/эха3 - запрашивать информацию или хэши только по указанным эхам
ну и всё. потом /e, /m, /u
что будет в дальнейшем - определяется только практичностью. пока - ничего не нужно, вроде.
[>]
Re: To 51t
im.100
spline(station13, 1) — 51t
2014-07-29 09:03:57
>что будет в дальнейшем - определяется только практичностью. пока - ничего не нужно, вроде.
Ну в целом да. Уже всё что надо есть, вроде. То есть совсем. Особенно я на блеклист не на радуюсь =)
[>]
Re: To 51t
im.100
spline(station13, 1) — 51t
2014-07-29 09:13:22
>/blacklist.txt - это список чёрных сообщений эхи. может применяться, например, клиентом, чтобы удалить весь навалившийся на него спам, разом, по нажатию кнопки
Этой фичи пока нет? Я чёт не нашёл в твоём клиенте (написал отдачу блеклиста).
[>]
list
im.100
ntrknlmp.exe(mira, 9) — All
2014-07-29 09:47:16
Я правильно понимаю, что на разных нодах list.txt находится по разным url относительно адреса ноды?
[>]
Re: list
im.100
51t(mira, 2) — ntrknlmp.exe
2014-07-29 09:48:24
> Я правильно понимаю, что на разных нодах list.txt находится по разным url относительно адреса ноды?
за схему берётся /u/
он находится в ../list.txt, относительно /u/
сейчас это везде работает
[>]
Re: офлайнизатор
im.100
51t(mira, 2) — spline
2014-07-29 09:49:35
ну, могу 502 ошибку показывать :) я у себя его делаю, думаю, как его лучше подавать :)
[>]
Re: list
im.100
ntrknlmp.exe(mira, 9) — 51t
2014-07-29 09:52:59
>за схему берётся /u/
>
>он находится в ../list.txt, относительно /u/
>
>сейчас это везде работает
на irk нет, почему и спрашиваю
[>]
Re: list
im.100
51t(mira, 2) — ntrknlmp.exe
2014-07-29 09:55:10
> на irk нет, почему и спрашиваю
мой клиент нормально загружает list.txt с ноды.
конечно, можно было и его в /u/ запихнуть, но, увы, он появился раньше, чем /u/ :)
[>]
Re: list
im.100
vit01(mira, 1) — ntrknlmp.exe
2014-07-29 10:37:54
Да не, ничего, всё нормально. Может посмотреть, как это в ncii реализовано, чтобы понятнее было.
[>]
Re: list
im.100
51t(mira, 2) — vit01
2014-07-29 10:56:37
у меня везде [:-2] используется
ps. первые поступления на off.51t.ru (эхи news, которая будет вбоку висеть и блестеть информацией - пока нет)
у меня к тебе вопрос - ты девочку, когда статьи брал, вообще как-то информировал. я автора анекдотов проинформировал, получил ответ "рад за вас", и вроде бы тут нормально... но если делать зону свободного контента - надо бы уточнить лицензию. надо решить или ты спроси, или я спрошу.