ну, просто меняешь конфиг

хэшкод
http://твойадрес:порт/ - обязательно с завершающим слешем
эха1
эха2
эха3

Ну вот видишь( как-то я внезапно на "ты" перешел,хм) уже есть некая информация, тянущая на маленький мануал

хотя, не, добавлять везде \n - это серьёзная ошибка, для пустых списков это будет лишняя пустая строка и невалидная эха...

> То есть, получается так: Алиса пишет в ноду foobar.2014 на сервере ii.foo.org; сервер ii.bar.net забирает это сообщение и хочет показать его своим пользователям, но ему стыдно — имя Алисы он не знает, знает только её пойнтовый номер. Верно понимаю?

нет. совсем не так.

foo.14 - это эха, а не нода. Алиса пишет на ноду ii.bar.net. Нода по её тексту проставляет на сообщение адрес, имя, и дату, и теперь нумерованное сообщение начнёт гулять по сети. И там все будут знать (со слов её нода), что это сообщение в эху foo.14 написала Алиса, что её адрес "lenina,92", что отправлено оно было под утро, и что звучит оно так - "ребята, это полый тест. мея видо!". Всё только со слов нода.

Можно посмотреть локалку vargos-а, наводя на моё имя в сообщении мышкой. Я там есть и как lenina,1 (с этой станции), и как test,2 - со станции Vargos-а.

Формально адрес - это вообще декорация. При работе с клиентом на 0.1c адрес вообще не подставляется корректно, поэтому я там есть и как 2, просто 2, без улицы :)

Эху создал, в list.txt записал, всё равно через браузер не заходит.

при веб-доступе к чему? к эхе, к главной странице? включи debug=True вместо debug=False и кидай трейсами

> Эху создал, в list.txt записал, всё равно через браузер не заходит.

какую эху создал, как?

название эхи, соответствует ли стандарту и фильтру?

В папке echo создал пустой файл testnode.2014, в list.txt записал её название, толку ноль, но в файле эхи появилось 2 байта пустого текста после попытки на неё зайти. Сейчас дебаг включу.

Попытка доступа была к главной странице

Как сюда файлы посылать? Или можно просто текст копипастить?

ок, перемещаюсь в другую эху

Всё верно, я, лопух, на ночь глядя слона не заметил — отправитель-то отдельной строкой идёт. (Ну, и опечатка нода-эха, да.)

Написать, что-ли, нодо-сервер на Go, чтоб REST API, push/pull-гейтование по HTTPS, вот это всё… Для облегчения гейтования какой-нибудь стандарт (единые URL'ы эх и мессаг, формат списка мессаг и т. п.) планируется?

> Написать, что-ли, нодо-сервер на Go, чтоб REST API, push/pull-гейтование по HTTPS, вот это всё…

можно, а зачем? имеющийся протокол значительно проще :) оно когда-то даже json отдавало, но я не смог придумать ни едного предназначения этому :)

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

> Для облегчения гейтования какой-нибудь стандарт (единые URL'ы эх и мессаг, формат списка мессаг и т. п.) планируется?

номер сообщения - 20 символов A-Za-z0-9

имя эхи - точно не помню, формат описан в документации, причём есть даже некое расхождение в echo_flt и в документации, надо будет к единому виду привести.

список - либо /e

номер
номер
номер

либо /z/e (у эхи есть символ ".", у номера сообщения - нет)

эха
номер
номер
номер
эха
номер
номер
номер


ну и сжатые бандлы и msgline-ы.

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

гейтование вообще простое :)

>> Написать, что-ли, нодо-сервер на Go, чтоб REST API, push/pull-гейтование по HTTPS, вот это всё…

> можно, а зачем? имеющийся протокол значительно проще :)

REST API — это так, до кучи; основной функционал в гейтовании: подписки и таскание бандлов туда-сюда.

PS: У Вас /msg лопнет рано или поздно.

ii://oz39DV25LQmyueA2eWfb или http://51t.ru/oz39DV25LQmyueA2eWfb

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

вот так вроде работает

if re.match('^[a-z0-9_!.-]{1,60}.\d{1,9}$',ea): return True

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

Gzip никто не отменял, как и архивацию каждые n-сообщений/ n-месяцев

> if re.match('^[a-z0-9_!.-]{,60}.\d{,9}$',ea): return True

Не работает потому, что: а) точка перед \d матчит любой символ, а не точку, эскейпить надо; б) {,9} и {,60} матчат пустую строку, надо {1,9} и {1,60} ставить. И вообще, регэкспы в Питоне рекомендуется как raw-строки задавать: r'foo'.

Как бы это не стало обязательной процедурой. А Maildir-подобное размещение файла не рассматривали? Типа такого:

/ii.dev.2014/1396264425.1dg3TzCgmf0hAdOAeC2n

…а список мессаг в эхе брать через readdir()/glob().

> опять эти непонятные регекспы...

И ещё момент: компиляйте регэкспы (help(re.compile)). Не то, чтобы скорости прибавлялось, и вообще экономия на спичках — зато удобно вынести их в шапку глобальными переменными для реюза и удобной правки.

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

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

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

или даже так

    if code == 1: txt += '</code>'
    if pre == 1: txt += '</pre>'
    return txt

в итоге собрал свой парсер

на 2кб, обрабатывающий частные случаи

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

обновилось всё, и в hg, и в архивах:

если ничего страшного не произойдёт, то это - всё :)

случилось страшное - я забыл ссылки: :)

http://51t.ru/s/ii-02.tar.gz
http://51t.ru/s/iiclient-02.tar.gz
http://51t.ru/s/iitxt-02.tar.gz

пожалуй, это лучшее фидо апреля

у меня сердце кровью обливается. ну nih-синдром же во все поля.
вот что стоило взять нормальный markdown, в который можно запилить своих обработчиков к тому же, и который нормально читается даже в тексте?..
и, например, стандартный multipart/form-data как вариант для сообщений с аттачами, который и в консоли распаковывается без особых проблем
ну или вот абсолютно фиксированный формат сообщения - почему было не взять привычные http-like заголовки?.. просто и расширяемо же.

моя не понимать.

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

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

потому что проще делать текстовые клиенты, хоть на tk, qt, хоть когда-нибудь голдед начать поддерживать, и если тащить форматирование в стандарт - это всё будет ужасно.

есть только три крайних случая:

это ответ, который надо выделять на любом клиенте, кроме txt
это плоский текст, который на html теряет форматирование и табы
и это гиперссылка, которую в вебе подчёркивать - это самая естественная вещь

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


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


про формат сообщений не понял. если про само устройство, то совершенно однозначно - простой текст по определённому номеру строки проще, чем, конечно, очевидный key: value. и разбирать его проще, даже с помощью head/tail

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

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

привет.

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

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

так на них же кнопка висит, где написана эха. кроме того, по этой кнопке можно прямо перейти на сообщение.

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

http://51t.ru/s/client-newmsg.png

вон, синяя кнопка с надписью ii.dev.2014

Да. Все верно. Немного путано, но разобрался. Пасиб.
Консольный клиент планируется?
P.S. Хм. Может самому сесть, написать

txt-клиент есть изначально. консольный - не знаю, хотелось бы, конечно, golded прикрутить :)

Здраствуй, товарищ!

Люди уже голдед свой на less пишут, пока ты спал :)

Не теряйся :)

сделать то можно, но интерфейс жалко, куча перегружаемых кнопок :(

мож на титл (ii.dev.2014 в данном случае) сделать переход не на главную, а просто на список эх?

ну, оно без системы аплинков/даунлинков не работает. :)

есть две станции, которые гейтуются друг с другом, обе со своим нодовым адресом:

http://51t.ru

http://n2.51t.ru:62220 (у неё там какой-то другой адрес, но я его забываю, просто сделал CNAME), там только один пойнт :)

и есть php-гейт, принимающий push, просто на всякий случай.

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

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

> прорегулярки там что-то было

посмотри php-код и то, что делает preg_replace.
нужен нормальный фильтр на имена.

а сайт парсить - оно тебе зачем. ты же не веб-интерфейс делаешь.

Про хеши: разобрался, надо в функцию hash для бинарных данных передавать третим параметром true
> посмотри php-код и то, что делает preg_replace.
функция getmsg, как я правильно понял?
> нужен нормальный фильтр на имена.
А какой конкретно? :)
> а сайт парсить - оно тебе зачем. ты же не веб-интерфейс делаешь.
Мне просто нужна поддержка поинтов в пхп ноде, я не собирался парсить сайт :)

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

то, что сейчас в php-коде - это вообще нечто ужасное. нужно хотя бы до питон-версии их довести

> И ещё: где (в каком файле) в питоновской версии записана логика поинтов?

там много где. логика пойнтов - это основная логика сайта. :)

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

Я уже решил портировать api на php, заодно изучу его получше

Можно, пожалуйста, поподробнее объяснить мне логику отправки сообщений на сервер.
Предположим, есть у меня на сервере get /u/point/pauth/tmsg post /u/point. Если я передаю сообщение через get, то вместо pauth вставляется пароль поинта, вместо tmsg сообщение, да? А если через пост, то как тогда?

https://bitbucket.org/51t/ii/src/2c694c20abdfbe43a37ada6e65e21c9576c690c9/tools/client-toss/tosspost.sh?at=default

https://bitbucket.org/51t/ii/src/2c694c20abdfbe43a37ada6e65e21c9576c690c9/tools/client-toss/tossposturl.sh?at=default

С этим понял. Теперь сообщение - это
эха
получатель или All
тема
пусто
msgid, на который отвечаем
любой текст на всех строках

Так?

да. кладжи пока приделаны кривовато, но вообще, оптимально, то, что начинается с первой строки с @xxx: yyy - это кладжи. сейчас только repto проверяется.

его может и не быть. т.е.

эха
получатель
тема

текст сообщения
текст

и кладжи, включая @repto, уже относятся к самому тексту. если клиент его не понимает - он его просто показывает, в надежде, что юзер сам разберётся, что это за информация. :)

сейчас идёт проверка только на @repto: - если первая строка начинается с @repto:, то считаем её кладжем, а текст сдвигаем на строку вниз. если нет - то считаем текст с первой строки.

кривоватая схема.... но так получилось :)

Доделаю завтра пхп ноду. Осталось доработать только запись сообщения в файл и проверки на ошибки сделать.
Сейчас спать, пока :)

кто-нибудь видел чисто python-овскую реализацию base64 code/decode

я по интернету поискал - не нашёл :(