> То есть, получается так: Алиса пишет в ноду 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, без улицы :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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 лет стало только хуже

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

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

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

или даже так

    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

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

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

нет, 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

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

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

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

Не теряйся :)

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

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

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

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

http://51t.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а зачем pastebin? есть же debug.14 :)

> Как в ii обрабатываются ошибки для клиента? Какие фильтры/ограничения/итд поставить?

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

добавил в битбакет и гитхаб ноду

версия - страшная, уже почти-почти 0.3, но прибираться потом будем, главное - чтобы проверить работоспособность

> для внедрения не рекомендуется вообще. ченчлог:

удалён /z

удалён /data

.header - шапка для эх для веб-интерфейса

rss - по умолчанию теперь отдаётся последние 50 сообщений, можно использовать /rss/echo/num для выбора или /rss/echo/0 для всех

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

добавлен blacklist.txt, чтобы не показывать некоторые сообщения в веб-интерфейсе

теперь данные берутся из того каталога, откуда запускается, т.е.
cd /home/iiserver + python /usr/share/iinet/run.py - все данные будут браться-сохраняться в /home/iiserver

server.cfg - новый формат, дополнительные описания для эх, перенос туда NODE и URL (потом будет переписано нормально)

добавил traf.py и ii.php - свою старую

просто, когда принимаешь, пиши 'msg ok:', если нет - 'error:' подробнее можешь в коде посмотреть, в point_msg или где-то там.

кода мож и много, зато под рукой. можно легко вырезать :)

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

нода сама вставляет имя пользователя, адрес, дату. читай tech.html на ii.51t.ru

то есть, схема такая.

тебе приходит письмо - эха, сабж, кому, текст

ты смотришь....

АГА! Я тебя знаю. Ты Иваныч. Значит, моя адресация 'kirova', а ты у нас в списке 22й. значит я леплю адрес 'kirova,22', msgfrom = Иваныч, и ставлю отметку о текущем времени. и создаю из этого - письмо.

на несколько тестовых эх сначала

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

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

пуш только по ключу должен проходить, там же есть nodepass

без фильтра она не будет видна в клиенте, на сервере и ещё много где. :) создать можно, когда не было половины фильтров, ala создал эху newecha, которая была доступна только в txt-клиенте, и нигде более :)

как оно иначе узнает, это номер сообщения, эха или ещё что-то?

api/flt.py

кто выдаёт, клиент.

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

прописал в клиенте

http://irk38.tk/ii/ii-point.php?q=/u/

и нормально получил все сообщения, всё видно

vit01 (mira, 1) (05/04 12:18 GMT)
msgto: root
Re: mysubj

Checking my php testnode


== 77 ========================= 7NBhdr4X0F3fNAzaTP1I
vit01 (mira, 1) (05/04 12:19 GMT)
msgto: All
Test else

dsfdsjfajdfgrje
32u325u32

5212t32it


== 78 ========================= 9xiA3cSE6iokT9bGTtVU
vit01 (mira, 1) (05/04 12:19 GMT)
msgto: All
test else

hshgohogronvbncjbujadbfosd
fdsfasd



32u5328tufewdgd

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

у меня и последний txt, и какой-то давно выкинутый в тест client (один из первых, поддерживающих /u/) - работают

скоро ii-dialog появится модный, судя по коммитам :)

пропиши меня пойнтом, хэш кинь на me@51t.ru - потестирую

работает. :)

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

msg_to_ii ($echo, $msg, $username, $addr, $date ....); в общем, чего там надо

и автоматически создаётся сообщение в нужном каталоге и запись в echo.

чтобы можно было в две строчки прикрутить это к любому сайту

и ещё надо сделать, что если нет нодокода, то не принимать push

если нет пойнтовых кодов, то не принимать пойнтов

т.е., побезопаснее по умолчанию.

и, наверное, где-нибудь на github/bitbucket открыть репозиторий. и искать тех, кого заинтересует. :)

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

> А вот тут не понял

а, в принципе, если ни один пойнт не прописан, она и так не должна позволять писать :)

да тот же самый используй, что и пойнтовый

в последней версии на битбакете есть нода с push. она же где-то в .dev валялась в виде текста