дурдом
6:6
пойду лучше анонимусов на лоре погоняю

ага :) просто, когда поболеть хочется :) вообще, тут ещё товарищ был, но он сейчас занят сильно, наверное... :)

кстати, Кузя победила. 9:7, по-моему

пью чай, думаю о народе

мы с пацанами бухаем на чайке, и не тока бухаем, я на своей тачке, чиксы тоже были...

http://51t.ru/s/me3.jpg

а нам вообще нужна эта эха?

не нашёл ответа на этот вопрос. эху скрыл.

Официальный маинтайнер проекта: irk38.tk

Ни 51t.ru, ни odii.ru больше не создают никаких пакетов и никаких версий, кроме кода в bitbucket и документации для него. Конкретные релизы и пакеты из кода создаёт проект irk38.tk, поэтому все его версии и пакеты - официальнее некуда.

Страница загрузки: http://irk38.tk/iidownload/

мне сейчас лень расписывать то, что уже несколько раз было расписано.

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

в angband 3.3.2 играешь?

а я чё-то включил его вчерась - (0.11.x в debian stable, 0.12.x в openbsd), чёт не моё.

ангбанд - хорош тем, что простой, как три рубля - чисто дум, только пошаговый и с rod of drain life на плече :) adom - замороченный какой-то, а в angband пошёл, и мочи эту нечисть. я дальше 31 этажа никогда не спускался, поэтому даже не представляю, чё там, и зачем я туда вообще попёрся. но вееесело :)

находка с клавишей Enter позволяет изучить весь интерфейс в процессе... все остальные рогалики для меня после этого - вообще непонятны, в nethack я как 10 лет назад два этажа с хрустом проходил, так и прохожу. а в angband я до 10-го этажа дохожу быстро и не заморачиваясь, даже если давно не играл.

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

моя душа принадлежит только ангбанду. и только версии 3.3.2 :)

питон-нода, видимо, уйдёт в устаревшие? :)

ты бы хоть адрес своей станции оставил, и список эх, как у spline :)

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

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

если есть пустая строка в тексте - неверно считает хедер:

конструкция:

header = new[:new.index('')]

выглядит круто и по-питоновски, но работает неправильно! критикал баг

или ещё что-то... в общем, плохо работает отправка.

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

1. счётчик "более 100" к клиенту - от исправления стало только хуже. надо исправить, чтобы нормально отображал, а не 100

2. приём /u/point - не падать по incorrect padding

это из обсуждения на лоре :)

3. некорректная обработка ссылок в цитате (добавляется </em>) решить можно или добавлением < в стоплист, или сменой очерёдности.

> Хочу j2me версию ii.

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

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

на sh портировать - вполне реально, нужны только base64, sha256 и запись-чтение файлов.

но нужно знать, что вам это нужно

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

не вижу проблемы - это a. нода должна принимать входящих юзеров, как я понимаю - это b.

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

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

А вообще - вы фетчер, вам и карты в руки. Хоть метод биссектрисы применяйте :) Вы же сами выбираете, что фетчить, никто вам не указ.

> 2. склайт

это обсуждали буквально вчера. и какой там формат, и какой способ БД может быть. к сожалению, обсуждали мимоходом и в im.1406, а не в dev. надо будет, наверное, это обсуждение перенести.

> 3. индексы эх и миграция
> есть ли планы убрать .14 из названий эх?

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

> я забью потому что это рутинная работа. рутинную работу должны делать компьютеры.

эту работу могут делать компьютеры


> 4. должен быть способ запросить все эхи с аплинка

да. я сегодня ещё буду объяснять, почему сложилоь так, а не иначе. только найду человека, который бы меня об этом спрашивал. :) в общем случае http://51t.ru/list.txt


> пожалуйста не быкуйте на лоре на людей у которых есть претензии к реализации сети. топик неприятно читать.

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

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

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

> когда памяти всего 32 мегабайта, 5 мегбайт для ноды - это очень много, там не отлько нода, там ещё другой софт должен работать.

поэтому и предложен был вариант либо "поток zlib + поток заголовков" либо "поток zlib в sqlite, с нужными заголовками"

> можете объяснить на пальцах в чём конкретно проблема? хеш, автор, дата, сабж, тело - это всё части сообщения, что мешает кроме хеша выдать ещё и дату? возможно я человек новый, но проблемы я не вижу. select id, date from msgs where date >= requested_date и выдать это в вывод.

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

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

> /m/ii.dev.14/1401767669

это было в версии 0.2. если хотите, сделайте hg checkout на нужную ревизию, и пользуйтесь. по нашим принципам, архив эхи XX - это архив, где всегда есть полная копия сообщений из этой эхи.

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

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


> ну объясните уже наконец один раз, напишите на какой-нибудь страничке в интернете

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


> в склайт это select id from echos и отдать поинту то, что есть у меня, такой же запрос можно сделать ко всем аплинкам, а они к своим аплинкам. получится p2p сеть в которой серией запросов можно собрать весть список эх и иногда обновлять. новые эхи будут постепенно расползаться по нодам.

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

> это не так важно, попробую объяснить. если курл читает чанками и сразу ложит в файл, то не важно злиб там или не злиб. но чтобы только запустить интерпретатор питона понадобится 3-5 секунд, а он ещё что-то делать должен. скорее всего он выест 100% 400-х мегагерцового мипса который стоит на этом роутере, залезет в своп да юсб-диске со своим сраным сборщиком мусора. тащить надо всю сеть by design. это значит, что если трафик в сети будет значительным, то роутер будет работать 24/7 постоянно копируя всю сеть. значит скорее всего он ничего другого делать не будет.

zlib - для сжатия. для минимального места на диске.

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

откровенно говоря, если вам не нужны пойнты, то всё, что вам нужно, работает вот так, хоть на busybox:

for e in `cat subscribe.list`
do
wget http://51t.ru/e/$e -O echo/$e

for m in `cat echo/$e`
do
wget http://51t.ru/m/$m -O msg/$m
done

done

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

скажите, вы фидо вообще видели? если да, то к чему эти вопросы - все основные принципы такие же.


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

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

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

вообще не понятно, к чему это.

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

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

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

оно взято из целесообразности.

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

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

> всем было насрать, что в эхах видны только новые сообщения.

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

> то, что предлагаете вы - я получаю архив за годкоторый никому не нужен, но тратит мои ресурсы

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

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

> вы всё таки не торопитесь, подумайте. не будете менять ii, да и хуй с ним, сделаете iii.

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

имеешь ввиду /u/push или /u/point? /u/push (нодовые сообщения) на этой ноде нет

/u/point:

передаётся POST-запрос вида:

pauth=authstr&tmsg=BASE64BASE64BASE64BASE64

в принципе, можно в исходниках сервера посмотреть shell-скрипты для постинга через wget, там всё понятно.


>> Файл текста отдавать, как есть
> Куда?

это касалось плоской спецификации. :) она увеличилась, а фрагмент остался. /m и /e. это надо вообще убрать :)

нет.

гет запрос - таким:

http://example.com/u/point/authstr/BASE64BASE64BASE64BASE64

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

пост-запрос - соответственно заполняются поля pauth и tmsg. тут можно использовать и urlsafe, и обычную base64

кстати, если пропустил - вот нода для любых экспериментов с любыми эхами:

http://iibbs.bl.ee

насоздавай себе эх по вкусу, и тесть

нахрена? к тому времени, когда это будет применимо, уже будут пост-запросы :)

> Попробуй выдернуть im.1406 одним куском, например.

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

> Что нахрена?

нахрена столько эх?

> Это что за зверь?

дикий совсэм... зато соврэмэнный... все в 1998 годе так дэлали, слюшай

> Как длинна бандла к количеству эх относится? Вот хочу я тянуть im.1406. И хочу тянуть кусками побольше =)

официальный клиент тянет по 40 собщений за раз. ты что, хочешь быть святее Ромы Римского?

> Какой ты, Рома, загадочный =)

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

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

я тебе могу без анализатора сказать, сколько будет длина. с / - 21 символ на сообщение.

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

это прототип, который должен доказать своё поведение на практике

это всё должно быть применимо как на веб-клиентах, так и на txt-клиентах (см., например, game.rogue.14)

это выглядит понятно и в plain-text, и в html. кроме этого, это и там и там выглядит одинаково.

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

это файл splitfilter.py, хоть в клиенте, хоть в сервере

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

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

ps. есть некоторые вещи, которые кажутся лишними. но это особенность foundation. я не понимаю css и подобное, если кто-то скажет, как исправить разночтение нескольких <pre>, тогда от этого можно будет отказаться

> В смысле разночтение?

в смысле, параметры межстрочных интевалов, и ещё очень много других, внутри <p>, сбрасываются при завершении <pre>

поэтому при

<p>
...
<pre>
....
</pre>
...
<pre>
...
</pre>
</p>

отступы и прочее у разных pre будут разными. поэтому сейчас </p> закрывается, и открывается новая. особенности foundation,

открыл - висит с no values, что происходит или не происходит - не знаю, на кнопки не отвечает

а можно сделать эхоменеджмент, как в ii://ii.dialog.14 или даже из него взять? чтобы мейлер отдельно, редактор отдельно.

во, я могу мышкой на эхи кликать. но ничего не происходит :(

о дай же мне дайже этого чудесного редактора! :)

о, нашёл мейлер. ctrl-f

а аутбаунд есть? чтобы написал, потом отправил, да ещё и сохранилось, что написал?