У нас же есть @repto.

У меня пишется, напимер:
>Tue Oct 20 13:25:06 2015
>From: vit01
>To: Andrew Lobanov in iing.15

> У нас же есть @repto.
Конечно, есть. Но тут в другом суть.

К примеру, Андрей написал какое-то сообщение. Предположим,
"123"

Ты на него ответил. Получилось
> 123
456

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

AL> 123
> 456
789

>AL>Вот я тут о цитировании задумался.
>А где пробел? =)

В начале строки =)

>VF> Может, вот так, с пробелом?

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

>> Ещё вот надо что-то делать с сабжем, ИМХО. У нас цитаты совершенно не указывают на то, кто их писал. Что мне нравится в Fido, там принято писать первые буквы имени, потом знак > и рисовать им отступ в один пробел.
>Идея хороша, но в стандарт это пропихивать не стоит. Пусть будет всего лишь наше негласное правило. Технических сложностей и так хватает.
Не то чтобы прям в стандарт. Стандарт описывает схемы и форматы, а это скорее рекомендации по квотированию. Просто идея для удобства чтения.

> Просто я имел в виду визуальный отступ перед сообщением, чтобы визуально его легче было отделять от текущего сообщения.
Тогда некоторые парсеры не будут выделять цитату как цитату (цветом, к примеру).

> Тогда некоторые парсеры не будут выделять цитату как цитату (цветом, к примеру).
Хотя нет, туплю, они же её и так не будут выделять =)

>>Просто я имел в виду визуальный отступ перед сообщением, чтобы визуально его легче было отделять от текущего сообщения.
>Тогда некоторые парсеры не будут выделять цитату как цитату (цветом, к примеру).

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

Если уж на то пошло, то я бы ещё внедрёжь для начала и конца сообщения присобачил, но мне кажется, что такое не пройдёт =)

PS: Зато как было бы красиво да.

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

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

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

2vit01: я имел в виду такой формат:

 AL> А давайте цитаты переделаем?
 VF> Идея занятная, но могут же возникнуть проблемы с парсером.

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

Как-то так.

> Ну тогда отступ на откуп клиентов. Но моё предложение в любом случае вынудит переписывать те парсеры. Как бы это ни было печально.
Насчёт переписывать не согласен. Мы же не будем переписывать парсеры схемы ii:// ссылок, если вдруг перейдём на echo:// и msg:// вместо них. Если точнее выразиться, то _добавить новые_ парсеры.

По идее несложно. Регулярка наподобие ^\s{1}[A-Za-zА-Яа-я]{2}>
Старый способ стоит оставить как более привычный.

Регулярку поправил, в base64 /x/file сделал.
Вечером всё протестирую и закоммичу. Даёшь обновы в ii!

Кстати, я планирую одну интересную фичу в Qt клиенте.

> Кстати, я планирую одну интересную фичу в Qt клиенте.
Это будет визуальный редактор для сообщений.
В общем, чтобы виндузятникам не устанавливать vim и всё такое.

>> Кстати, я планирую одну интересную фичу в Qt клиенте.
>Это будет визуальный редактор для сообщений.

Я думал нечто подобное сделать у себя, но текстовый редактор писать на ncurses просто мотовство, когда рядом есть столько редакторов да с поддержкой aspell =)

Сделал коммит и обновил резервную ноду http://alicorn.tk/ii/ на ветку features. Теперь там можно (наверное) создавать эхи без цифровых постфиксов, использовать новую схему /u/e и делать ещё что-то, что мы обсуждали.

Насчёт /x/file и base64.
Ради интереса пропихнул в список файл размером 188 мб. Поскольку чтение файла и его расшифровка происходит "в лоб", PHP крашится от недостатка ОЗУ.

Файл размером ~4 мб читается без напряга.

Подтверждаю, что оно работает =)

http://alicorn.tk/ii/?echo=ii.test

>Насчёт /x/file и base64.
Ух ё! Нахер там base64???

Храни ключ=>значение, типа:

{
  'filename': '/path/to/file/in/fs/'
}

Отдавай бинарем и получай бинарь.

>Ради интереса пропихнул в список файл размером 188 мб
Ради интереса посмотри сколько он будет весить в base64 :D

cat ~/soft/iso/debian-8.2.0-amd64-netinst.iso | dd of=/dev/null
505856+0 записей получено
505856+0 записей отправлено
 скопировано 258998272 байта (259 MB), 2,25618 c, 115 MB/c

cat ~/soft/iso/debian-8.2.0-amd64-netinst.iso | base64 | dd of=/dev/null
683349+1 записей получено
683349+1 записей отправлено
 скопировано 349874862 байта (350 MB), 0,473237 c, 739 MB/c

> Ух ё! Нахер там base64???
На случай передачи по ненадёжным каналам данных =)
Хотя, конечно, по быстродействию это не лучшим образом выглядит.

> Ради интереса посмотри сколько он будет весить в base64 :D
На 33% больше, как и полагается в base64.

>> Ух ё! Нахер там base64???
>На случай передачи по ненадёжным каналам данных =)
Что ты имеешь в виду? Как base64 поможет?

> Что ты имеешь в виду? Как base64 поможет?
Посмотри, что Андрей написал выше в эхе.

>Посмотри, что Андрей написал выше в эхе.
Ты про это?

>ii хоть и завязан плотно на http, но чисто теоретически является паразитической сетью, которая должна работать поверх произвольного протокола. Может стоит реализовать файлы с base64-кодированием, а не просто по http отдавать файл?


Поверх чего угодно можно отдавать бинарники. Будь то HTTP, FTP, SSH или файлы на дискетах.

Короче, я против base64 в файловом протоколе.
Но вы можете пилить, что угодно в схеме x :)

base64 это было первое, что пришло мне в голову. В принципе, можно отдавать и бинарь, наверняка если мы заменим http на другой произвольный протокол, мы всё равно сможем гнать бинари. Надо думать и спрашивать бывалых, а я ламер =)

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

Кстати, в цезии поддержка уже появилась? Я вон в ii://mlp.15 даже маленький скрипт на третьем питоне кидал, чтобы файлы скачивать.
// толку от него всё равно мало, 500-мегабайтные видео не передать из-за base64 ;)

Только что поменял на вариант без base64 у себя на локалхосте и немного подправил скрипт. Теперь видео на ~950мб скачивается без проблем.

Что, даже здесь особо никто не сидит? Чем быстрее проработаем схемы, тем быстрее на них перейдём.
Обратный переход с base64 на бинари (по скорости лучше) до сих пор висит незакоммиченный, надо что-то делать со стандартами, в конце концов.

>Что, даже здесь особо никто не сидит? Чем быстрее проработаем схемы, тем быстрее на них перейдём.
Я здесь. Завтра попробую объединить всё, что наобсуждали и уже смотреть более детально.

>Обратный переход с base64 на бинари (по скорости лучше) до сих пор висит незакоммиченный, надо что-то делать со стандартами, в конце концов.
Бинари надо отдавать бинарями. Difrex всё правильно сказал.

Тогда...

Коммит.

// кстати, ещё с веб-интерфейсом поработал немного

>>ЗЫ: Первый фичреквест(я все же клиент пилю, а не сервер): хочу получать последние сообщения от msgid типа
>>====
>>curl http://node/m/e/t/h/o/d/echo.15/MsGiD
>>{
>> [
>> 'msgid': unixtime,
>> 'msgid2': unixtime
>> ]
>>}
>>====
>Я думал это реализовать со стороны клиента, но это увеличило бы количество запросов.
Вот я тоже думаю. В любом случае, такая штука может дать сбой, если "на лету" менять ноду. Но без переездов бы она сильно упростила жизнь.

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

unixtime смущает. Это что получается: сервер должен распарсить все N тысяч сообщений на время?

Я тут немного покумекал и задумался. А что нода должна возвращать, если указанного msgid нет в эхе?

Моя реализация ноды теперь умеет три фичи в методе /u/e:
1. Классическое для ii поведение.
2. Если в поеследнем аргументе указаны начальное:сообщение:смещение, то возвращает указанный диапазон.
2.1. Если начальное сообщение находится за пределами списка сообщений то берётся первое или последнее (в зависимости от знака указанного индекса).
2.2. Если начальное сообщение + смещение указывает за пределы списка сообщений в эхе, то возвращаются все сообщения с указанного начального по последнее в эхе.
3. Если в последнем аргументе указан msgid, то нода возвращает всё, что есть в эхе после него.
3.1. Если такого сообщения нет, то возвращается вся эха целиком.

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

Какие будут предложения? Нужен ли вобще такой метод?

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

> Какие будут предложения? Нужен ли вобще такой метод?

Третий пункт попахивает костылями. Во-первых, хорошо было бы указывать начальный msgid для всех запрошенных эх, т.е. в текущем варианте от него мало пользы. Во-вторых, /u/e и так смещения еле-еле в себя вобрал.

В общем, я за ещё одну схему для списка по msgid.

>> Третий пункт позволяет очень много получить странного в текущем виде, так как можно указать несколько эх, а один msgid может быть только в одной эхе (в подавляющем большинстве случаев).
>Третий пункт попахивает костылями. Во-первых, хорошо было бы указывать начальный msgid для всех запрошенных эх, т.е. в текущем варианте от него мало пользы. Во-вторых, /u/e и так смещения еле-еле в себя вобрал.
>В общем, я за ещё одну схему для списка по msgid.
По доброму, я бы смещения тоже отдельным методом сделал. Хотя они и куда менее опасные, в сравнении с msgid.

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

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

> Кстати, как ты предполагаешь забирать свежую почту в новом стандарте? Например, клиент всегда забирает последние 50 сообщений, но новых сообщений в эхе 75. Или клиентскую часть ты пока не реализовывал?

Клиентскую часть пока не реализовывал, но скоро собираюсь. Насчёт алгоритма забора почты уже рассказывал: если все 50 сообщений из первого списка новые, то идёт забор -100:50 и так далее аналогично. А сабжевую возможность планирую сделать опциональной (галочка в настройках).

Сабж без веб-интерфейса (пока что) лежит вот тут: https://github.com/spline1986/ii

Буду рад, если найдутся желающие потыкать это поделие палочкой =)

>> Вот я тоже думаю ... Но без переездов бы она сильно упростила жизнь.
>unixtime смущает. Это что получается: сервер должен распарсить все N тысяч сообщений на время?

Только если нода хранит сообщения в файликах, а не в базе.

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

AL>Буду рад, если найдутся желающие потыкать это поделие палочкой =)
Попробовал написать несколько сообщений в тестовую эху. Обнаружился баг: при обычном запросе /u/e/эха сообщений на 1 меньше, чем в индексе. Отсекается последнее почему-то.

AL>>Буду рад, если найдутся желающие потыкать это поделие палочкой =)
vit01>Попробовал написать несколько сообщений в тестовую эху. Обнаружился баг: при обычном запросе /u/e/эха сообщений на 1 меньше, чем в индексе. Отсекается последнее почему-то.
Поправил. Теперь всё совсем жёстко. Если запись в индексе не является msgid (не проходит фильтр), то она не попадает в выхлоп запросов.

Добавил новую регулярку для цитирования и наконец-то закоммитил ii2rss.php, который за это время вполне удачно себя проявил в деле.

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

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

Закоммитил подсветку комментариев в сабж. И заодно в свой Qt-клиент.

В сабже пополнение: скрипт для скачивания через /x/t
Ничего необычного, все маленькие полезные скрипты для работы с ii должны туда рано или поздно попасть.

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

AL> Очевидно, что на разных нодах может быть разный порядок сообщений в эхах или даже разное содержимое. В связи с чем, я пока придумал только держать отдельную базу сообщений для каждой из нод.
В Qt-клиенте для всех нод одна и та же база. Алгоритм работы примерно таков:
1. Фетчим одну и ту же эху с нескольких нод в одно и то же место
2. Если отправляем туда сообщение, то оно уходит на первую ноду из списка

Каждый из вариантов имеет свои плюсы. Я не стал городить раздельные базы, потому что юзер-НЕфрендли. А произвольную отправку не стал делать, потому что лень =)

AL>> Очевидно, что на разных нодах может быть разный порядок сообщений в эхах или даже разное содержимое. В связи с чем, я пока придумал только держать отдельную базу сообщений для каждой из нод.
vit01> В Qt-клиенте для всех нод одна и та же база. Алгоритм работы примерно таков:
vit01> 1. Фетчим одну и ту же эху с нескольких нод в одно и то же место

Пока что я так же сделал, но вопрос был задан в свете эхотага. Когда клиент забирает не весь список, а только n последних сообщений в эхе.

vit01> 2. Если отправляем туда сообщение, то оно уходит на первую ноду из списка

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

vit01> Я не стал городить раздельные базы, потому что юзер-НЕфрендли.

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

зы Вопрос пока что чисто теоретический.

vit01>> 2. Если отправляем туда сообщение, то оно уходит на первую ноду из списка

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

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

vit01>> Я не стал городить раздельные базы, потому что юзер-НЕфрендли.

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

И где здесь проблема? Предположим, есть эха news.15. На станции 1 туда, к примеру, постят новости с Лора, а на станции 2 - с опеннета. Юзер фетчит их в одну базу. В итоге получает _одну_ ленту с новостями обоих сайтов. Так даже читать приятнее.

AL>> Пока у меня одна база, так как нет смысла, но когда у нас будет возможность получить разный набор сообщений с разных нод, это может стать проблемой.
vit01> И где здесь проблема? Предположим, есть эха news.15. На станции 1 туда, к примеру, постят новости с Лора, а на станции 2 - с опеннета. Юзер фетчит их в одну базу. В итоге получает _одну_ ленту с новостями обоих сайтов. Так даже читать приятнее.

А когда в эту эху с ноды 1 приходят новости с опеннета, а со второй -- с хабры, и с обоих нод репостится ЛОР, то есть вероятность, что поинт будет получать не все сообщения. Причём весьма высокая. Просто потому, что тогда совсем разный порядок сообщений может оказаться. Я понимаю, что это будет не так удобно для пользователя, но зато позволит не изобретать извращённых алгоритмов для разруливания этой путаницы.

AL>>> Пока у меня одна база, так как нет смысла, но когда у нас будет возможность получить разный набор сообщений с разных нод, это может стать проблемой.
vit01>> И где здесь проблема? Предположим, есть эха news.15. На станции 1 туда, к примеру, постят новости с Лора, а на станции 2 - с опеннета. Юзер фетчит их в одну базу. В итоге получает _одну_ ленту с новостями обоих сайтов. Так даже читать приятнее.
AL> А когда в эту эху с ноды 1 приходят новости с опеннета, а со второй -- с хабры, и с обоих нод репостится ЛОР, то есть вероятность, что поинт будет получать не все сообщения. Причём весьма высокая. Просто потому, что тогда совсем разный порядок сообщений может оказаться. Я понимаю, что это будет не так удобно для пользователя, но зато позволит не изобретать извращённых алгоритмов для разруливания этой путаницы.

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

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

Ну а так они и без одноимённых эх могут теряться, тут разницы нет большой.

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

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

vit01> Ну а так они и без одноимённых эх могут теряться, тут разницы нет большой.

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

> И если создать разные базы для разных нод, то потерь не будет.

Требую наглядного примера (запрос => результат => файл в общей базе)