Сабж над клиентом. Теперь оно будет модульным (насколько возможно). Соответственно, если будет не лень, будут поддерживаться web-интерфейс, ncurses-интерфейс и вполне возможно что gtk или даже sdl =) Пока всё таки над ncurses-мордой работаю. Тяжеловато на ncurses писать без прослоек =(

Скриншот: http://spline.rooker.ru/screen_20140804.png

Это же лисповый клиент, да?

Надо будет его еще раз попробовать =)

>Это же лисповый клиент, да?

Он да.

>Надо будет его еще раз попробовать =)

Рано его ещё пробовать. Для меня писать на ncurses слишком сложно. Потому он уже поддерживает все нужные фичи ii (/u/, /list.txt, /blacklist.txt, бандлы), но ещё не имеет интерфейса. Когда будет хотя бы на уровне первой альфы, я в ii* кину анонс.

>Когда будет хотя бы на уровне первой альфы, я в ii* кину анонс.
Значит, будем подождать.

>Потому он уже поддерживает все нужные фичи ii (/u/, /list.txt, /blacklist.txt, бандлы)
> /blacklist.txt
Чёрный список никаким образом не входит в стандарт. Да, отдача его не запрещена, но вот так он не отдаётся. Лучше сделать так, чтобы его адрес можно было указывать вручную (чтобы обеспечить возможность, к примеру, чистить сообщения из разных чёрных списков или даже просто из файла).

>Чёрный список никаким образом не входит в стандарт.

Я не писал что он поддерживает только стандарт. Я говорил что он поддерживает все нужные фичи.

Поддержку /x/ мне пока не хочется делать, так как не совсем понятно что там и как, за исключением таймстампа есть.

>Я не писал что он поддерживает только стандарт. Я говорил что он поддерживает все нужные фичи.
То есть ты как бы сказал, что он может чистить базу по чёрному списку, но про получение этого списка не говорил. Так? Просто я мог неправильно понять.

>Поддержку /x/ мне пока не хочется делать, так как не совсем понятно что там и как, за исключением таймстампа есть.
Таймстамп необязателен, суть /x/t - это версия базы (см. статья расширения на iinet.sexy). К примеру, на php ноде он реализован как количество сообщений, а не как таймстамп.

Кстати, to gadfly
Поддержка /x/t в форке клиента имеется? А то когда я на даче, сообщения загружаются так неспешно :) Могу и пакет собрать, если есть эта фича.

>То есть ты как бы сказал, что он может чистить базу по чёрному списку, но про получение этого списка не говорил. Так? Просто я мог неправильно понять.

Пока он получает blacklist.txt с ноды. Возможность альтернативного получения/создания чёрного списка пока не предусмотрена, но никто не говорит что её не будет =)

>Таймстамп необязателен, суть /x/t - это версия базы (см. статья расширения на iinet.sexy). К примеру, на php ноде он реализован как количество сообщений, а не как таймстамп.

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

>А то когда я на даче, сообщения загружаются так неспешно :)

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

> Пока он получает blacklist.txt с ноды.
А как он его получает, если у каждой ноды чёрный список хранится и выдаётся в разных местах? =) Тем более, у ноды их может быть несколько, а не один, поэтому такое лучше указывать вручную.

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

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

> Рома правильно сказал что проще было бы использовать хеш эхи.
Проверка по хэшу может породить ошибки, если расположение сообщений в локальной эхе и эхе на ноде различается (у нас же всё-таки распределённость). Избежать ошибок можно точно так же в случае хранения хэша отдельно и отдельно для каждой ноды. Кстати, у него такая фича реализована довольно костыльно (я про схему api), а у нас гораздо проще и удобнее.

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

> Поддержка /x/t в форке клиента имеется? А то когда я на даче, сообщения загружаются так неспешно :) Могу и пакет собрать, если есть эта фича.

вернуть то, что было в версии 0.2 - это вообще вопрос четырёх строк в файле сервера (+1 вызов) в сервере и добавление 4 строк в один-единственный файл в одну единственную функцию - клиенте.

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

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


при этом совместимость не ломается вообще, ни в одну сторону.

> Проверка по хэшу может породить ошибки

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

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

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

> Пока он получает blacklist.txt с ноды. Возможность альтернативного получения/создания чёрного списка пока не предусмотрена, но никто не говорит что её не будет =)

Спроси их, зачем нужно несколько блеклистов :)

> Это ещё менее надёжный способ нежели таймстамп. Меняем ноду

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

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

> Возможны, конечно, коллизии, но их будет явно меньше.

коллизии невозможны :) надо понимать, что такое sha256 :)

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

Если есть /x/ это ещё не значит что нет /u/. А раз есть /u/ то и совместимость есть. Пусть хоть 100500 расширений будет, пока есть /u/ совместимость останется. Не написать в клиенте втупую /u/ как это было ещё в 0.3 это уже болезнь и я ещё подумаю стоит ли такой клиент использовать. Я пока сосредоточился на /u/, /list.txt и /blacklist.txt. Когда оно будет работать без ошибок, может и займусь всякими /x/ и прочими извращениями. Пока что не вижу смысла в них. Как и в нескольких blacklist'ах.

>коллизии невозможны :)

уже доказано?;)

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

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

Буду делать свой форк клиента, с /x/t и постраничной навигацией.

> Если есть /x/ это ещё не значит что нет /u/.

Вообще, из изначального замысла протокола так и было. Что /u/ или /z/ или /x/ - это полный набор всех методов, чтобы не было "чуть чуть того, чуть чуть этого". Это и однозначный сигнал как для сервера, так и для клиента "работаем в таком-то режиме". Чтобы упростить жизнь стандартами. Но идея попала в плохие руки, и сейчас там "подёргай то, подёргай это", всё кусками :)

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

Оно не может "ничего не работать". в принципе. самое сложное, что может "не работать" - это

> Ведь сломать совместимость - это значит, что работающее раньше не работает сейчас.

Я давно заметил, что вы очевидных вещей не пониаете.

> Про сломанную совместимость прошу доказательств.

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

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

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

Поэтому я считаю, что это бред - спорить с дилетантами, которые либо принимают всё, как данность, которое сделалось само (а не на основании огомного опыта) и на которое можно просто нахлобучивать всё, и ничего вроде бы не изменится (потому что ОНИ не видят всех этих нюансов, у детей интернета восприятие линейное), либо считают, что их поверхностные знания могут служить фундаментом сети. Да ещё и меня поучают, как правильно. :)

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

на тех объёмах и том формате, который используется для списка - да :)

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

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

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

не знать не зазорно. зазорно не знать и при этом лезть ломать :)

> Лично я считаю что ненужные расширения в отдалённой перспективе просто сломаются.

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

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

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

>> Ведь сломать совместимость - это значит, что работающее раньше не работает сейчас.
> Я давно заметил, что вы очевидных вещей не пониаете.
> Так это потому, что вы и сути ii не понимаете. Форму понимаете, а сути - не понимаете.
Ну давай, расскажи, как это понимаешь ты.

>> Про сломанную совместимость прошу доказательств.
> Доказательств чего? Что вместо простого прозрачного стандарта стала куча расширений, которые какие-то клиенты умеют, какие-то - не умеют, и эта разница только будет расти и шириться, и людям придётся принимать нафиг не нужный им выбор, нужны ли им эти расширения?
Если не нужно - пусть не используют. Расширения (вообще любые, те же /list.txt и /u/push к ним относятся) - это вещь необязательная. Они используются именно тогда, когда нужны. Если они не нужны, их можно убрать. Если /u/ остался, то всё нормально, совместимость не пострадала.

> Это всё потому, что передо мной очередные дети интернета. Которым поверхностные знания заменяют фундаментальные. Которые кроме проецирования своих навыков на все остальные области и перечисления фактов, котоорые где-то услышали
> Поэтому я считаю, что это бред - спорить с дилетантами, которые либо принимают всё, как данность, которое сделалось само (а не на основании огомного опыта) и на которое можно просто нахлобучивать всё, и ничего вроде бы не изменится (потому что ОНИ не видят всех этих нюансов, у детей интернета восприятие линейное), либо считают, что их поверхностные знания могут служить фундаментом сети. Да ещё и меня поучают, как правильно. :)
> Вообще-то мой проект был задуман именно для того, чтобы вести общения не с детьми интернета, а с людьми разумными, желательно, конечно, имеющими что-то от советского фундамента, и обмениваться компетентностью и опытом... своим, а не чужим.
Опять начинаешь свою обычную песню "вы все плохие, а я один хороший".

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

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

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

> андроид-клиент уже не работает по каким-то причинам на моей ноде
Я сейчас специально поменял адрес ноды в андроид клиенте на 51t.ru, и у меня всё работает (сообщения загружаются). Что не так?

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

они не будут КАЖДЫЙ раз. они будут ОДИН раз.

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

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

> Ну давай, расскажи, как это понимаешь ты.

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

то, что я вижу, это "а давайте прифигачим и будет круто". ради самого прифигачения.

> Если не нужно - пусть не используют. Расширения (вообще любые, те же /list.txt и /u/push к ним относятся) - это вещь необязательная. Они используются именно тогда, когда нужны. Если они не нужны, их можно убрать. Если /u/ остался, то всё нормально, совместимость не пострадала.

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

Поверх основы (/list.txt, /m /e), которые были необходимы, сверху добавлены только /u/e и /u/m для пакетной передачи, потому что это СИЛЬНО ускооряет работу, и /u/point, чтобы, собственно, слать сообщения. Всё, это и есть стандарт, это и есть основа ii. Это и именно это должен реализовывать каждый клиент, и именно об этом знать. О конкретных мелочах, нужных для него - узнавать только в процессе эксплуатации и понимании сути культуры ii и того, на чём она держится. То, что было сверх этого, в версии после 0.2 было убито, чтобы просто не создавать неразберихи и стандартизировать все клиенты - чтобы все клиенты умели одну вещь и умели хорошо, а не сидели и выбирали, ещё до того, как создадут клиент, каких бы методов им набрать. Однозначные решения принимать всегда проще.

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

Ага. она потребовала 20 секунд на реализацию, 2 строчки, без революций, и для тех, кому это не надо - НЕ ИЗМЕНИЛА ВООБЩЕ НИЧЕГО. и при этом полностью закрыла проблему.

Я уж молчу, что схему параметров создавал я, и /x/ туда тоже не вписывается, потому что каждая схема должна быть САМОДОСТАТОЧНОЙ и включать вообще всё, чтобы не было кусков. Это именно "стандартная схема параметров из api".


> Опять начинаешь свою обычную песню "вы все плохие, а я один хороший".

не я плохой, а вы хорошие, а "я строю, а вы ломаете".


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

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

> Давай расскажи, чего ты знаешь такого, чего мы должны знать, а то уже зазорно как-то стало :) К тому же, ничего пока не сломано.

А, по-моему, я именно то и говорю, что фундаментальные знания, и ВСЕ нюансы нельзя объяснить на пальцах. И что сейчас у детей интернета иллюзия, что они всё знают, а что не знают, могут быстро прочитать, и, хоп, тоже знают. Может, они и знают, но точно - нихрена не понимают.

> Я сейчас специально поменял адрес ноды в андроид клиенте на 51t.ru, и у меня всё работает (сообщения загружаются). Что не так?

Читай сизю. Он сообщений 50 по этому поводу написал, как у него не обновляются последние сообщения.

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

А между тем в иксах именно так и сделано. Запросил список расширений - что поддерживаешь, тем и пользуйся. Ничего не поддерживаешь - fallback.
Они тоже глупые дети 3D и мультиков?

>Я могу говортить, что примерно разбираюсь в HTTP-протоколе, потому что давным-давно я писал http-сервер, полностью с нуля, и реализовывая вручсную все-все его компоненты, разбор url, http-заголовки (+редиректы, формы, куки), роуты... в общем, я примерно представляю, о чём говорю, потому что на практике это воссоздавал и решал возникающие проблемы, разбирая особенности. Когда я говорю про фидо - я годами наблюдал, как это работало, какие проблемы возникали там, как их решали. Да и сам утилиты для фидо писал, чтобы как-то жизнь облегчить.

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

>Поэтому я считаю, что это бред - спорить с дилетантами, которые либо принимают всё, как данность, которое сделалось само (а не на основании огомного опыта) и на которое можно просто нахлобучивать всё, и ничего вроде бы не изменится (потому что ОНИ не видят всех этих нюансов, у детей интернета восприятие линейное), либо считают, что их поверхностные знания могут служить фундаментом сети. Да ещё и меня поучают, как правильно. :)

Звучит как будто ты против свежих идей;) Жизнь не стоит на месте, если раньше люди писали запросы в бд ручками, то сейчас используют orm.

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

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

>андроид-клиент уже не работает по каким-то причинам на моей ноде

Там вообще нет ничего, кроме /u/
Может скорее проблема в прошивках и людях, которые кричат "говно!", вместо поиска проблемных мест?

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

Как у него реализовано? если как и в /u/, то наоборот мне кажется это наиболее удачный вариант)

>Я сейчас специально поменял адрес ноды в андроид клиенте на 51t.ru, и у меня всё работает (сообщения загружаются). Что не так?

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

> А между тем в иксах именно так и сделано. Запросил список расширений - что поддерживаешь, тем и пользуйся. Ничего не поддерживаешь - fallback. Они тоже глупые дети 3D и мультиков?

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

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


> так вот, запоминать свой хеш для авторизации это "социально"?

это фидошно. его и запоминать не надо. для веба - забил ссылку для автологина, для клиента - забил строку в клиент.


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

А ты просто не понял, что именно я сделал. Поэтому и судишь со своего уровня. Концепция - это такая вещь, которая частности собирает в общее. где "тут тронь" - оно и развалится. Впрочем, начинать надо с того, кто изначально принимается за ноды ii. То есть, рассказывать всю историю, цели и задачи с самого начала.

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


> Звучит как будто ты против свежих идей;)

Я против подмены понятий. Лучше одна хорошая идея, чем постоянный выбор из 700, из которых 500 плохие и 150 ужасные. Я не вижу ничего хорошего в "свежих идеях", которые часто встречаю: это больше похоже на генератор из пустого в порожнее, минуя смысл.


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

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


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

Эээээээ... уэаээээ... даже не знаю, как это комментировать, честно.

> Может скорее проблема в прошивках и людях, которые кричат "говно!", вместо поиска проблемных мест?

человек в подробностях и в десятках сообщений расписал свои проблемы и способ их воспроизведения...

> Как у него реализовано?

http://hg.51t.ru/ii/file/ac150c296da6/run.py#l19

через list.txt. описание подменяется хэшами.

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

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

>то, что я вижу, это "а давайте прифигачим и будет круто". ради самого прифигачения.
Нет, это делается, потому что нужно. Вот мне понадобится, я скоро сделаю.

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

>Поверх основы (/list.txt, /m /e), которые были необходимы, сверху добавлены только /u/e и /u/m для пакетной передачи, потому что это СИЛЬНО ускооряет работу, и /u/point, чтобы, собственно, слать сообщения. Всё, это и есть стандарт, это и есть основа ii. Это и именно это должен реализовывать каждый клиент, и именно об этом знать. О конкретных мелочах, нужных для него - узнавать только в процессе эксплуатации и понимании сути культуры ii и того, на чём она держится. То, что было сверх этого, в версии после 0.2 было убито, чтобы просто не создавать неразберихи и стандартизировать все клиенты - чтобы все клиенты умели одну вещь и умели хорошо, а не сидели и выбирали, ещё до того, как создадут клиент, каких бы методов им набрать. Однозначные решения принимать всегда проще.
Так эту основу неё убирали, она работала и будет работать.

>Ага. она потребовала 20 секунд на реализацию, 2 строчки, без революций, и для тех, кому это не надо - НЕ ИЗМЕНИЛА ВООБЩЕ НИЧЕГО. и при этом полностью закрыла проблему.
То же самое. У нас так же.

>Я уж молчу, что схему параметров создавал я, и /x/ туда тоже не вписывается, потому что каждая схема должна быть САМОДОСТАТОЧНОЙ и включать вообще всё, чтобы не было кусков. Это именно "стандартная схема параметров из api".
Это помню

>не я плохой, а вы хорошие, а "я строю, а вы ломаете".
/u/ не сломали, а немного добавили вне него.

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

>Читай сизю. Он сообщений 50 по этому поводу написал, как у него не обновляются последние сообщения
Читал уже, помню. У меня, в отличие от него, версия андроида 4.4, поэтому у меня всё работает

>Как у него реализовано? если как и в /u/, то наоборот мне кажется это наиболее удачный вариант)
Сейчас почитаю исходники. Но по-моему, там другой вариант

>человек в подробностях и в десятках сообщений расписал свои проблемы и способ их воспроизведения...

Да да, я их воспроизвел у себя на двух девайсах и все работало. Ну и как мне прикажешь решать их проблемы? И самое главное - кому он расписал?

пиздец.

извиняюсь, но других слов тут нет.

> Ну и как мне прикажешь решать их проблемы?

не знаю. но на вашей ноде оно у него отлично работает, а на моей - нет.

> И самое главное - кому он расписал?

эхе.

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

Добро пожаловать в 21 век.

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

Пришел на работу, хочу написать к вам на 51t, хэш не помню, а тут ведь компьютер другой. Автологин? А там в конце параметр случайно не хэш?;)

> Добро пожаловать в 21 век.

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


> Пришел на работу, хочу написать к вам на 51t, хэш не помню, а тут ведь компьютер другой. Автологин? А там в конце параметр случайно не хэш?;)

1. guest

2. в деревню! к тётке! в глушь! в саратов! там будешь горе горевать, за пяльцами сидеть за святцами зевать (или типа того)

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

пример: ?q=/list.txt&h=1&el=im.100/ii.test.14
у нас же аналогичное: ?q=/x/t/im.100/ii.test.14

какая СКРИПТУ (подчёркиваю, СКРИПТУ) разница, какой именно url? это уже за гранью бреда какого-то, выискивать идеологию в тексте стороннего запроса.

>какая СКРИПТУ (подчёркиваю, СКРИПТУ) разница, какой именно url? это уже за гранью бреда какого-то, выискивать идеологию в тексте стороннего запроса.
Скрипту разницы 0, а разработчику есть. Дело в том, что это в общую схему не вписывается, и прикручено как попало. В случае схемы это бы удобнее реализовалось и вписывалось в общую концепцию. А так - суть одна и та же.

в какой схеме?

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

зато это делается в две строчки и не добавляет ничего нового в протокол, и для большинства людей этого просто нет. а в качестве примера использования в tools/other будет чекер, но он будет только для conky или подобного. ПОТОМУ ЧТО В РАМКАХ КЛИЕНТА ОН ВООБЩЕ ПРОБЛЕМ РЕШИТЬ НЕ В СОСТОЯНИИ. в состоянии только создать новых. в качестве ненадёжной договорённости во имя экономии - есть sfmode, который не меняет ни схему, ни протокол, ни url - вообще ничего. подобные патчи, которые просто реализуются, просто откатываются, и ничего не меняют, это часть ---культуры openbsd--- идеологии ii, та основа, которая позволяет и не терять практичности по потребности, и при этом не усложнять конструкцию, схему и подобное. что оно есть, что его нет - разницы быть не должно, авторов клиентов это в момент первой реализации клиента вообще не должно волновать, и первый рабочий "чистый" клиент делать будет проще и быстрее.

>в какой схеме?
В схеме параметров. Стандартный запрос к ii-серверу состоит из строки, состоящей из слешей и того, что находится между ними.

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

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

Кстати, я заметил неоднозначность: в случае твоего способа запроса у python ноды на втором параметре надо ставить вопрос, а у php ноды амперсанд. При следовании стандартной схеме такого бы не произошло.

> В схеме параметров. Стандартный запрос к ii-серверу состоит из строки, состоящей из слешей и того, что находится между ними.

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

> Так понятно. Это расширение, реализовывать которое совсем необязательно.

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

> Кстати, я заметил неоднозначность: в случае твоего способа запроса у python ноды на втором параметре надо ставить вопрос, а у php ноды амперсанд. При следовании стандартной схеме такого бы не произошло.

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

И именно поэтому чётко написано "НИКАКИХ, ВАШУ МАТЬ, ФИЧ", ибо они рушат идеологию на корню. Можно сделать другой проект, фичастый, очертить круг задач, продумать детали и принять компромиссы, которые позволяют лучше их решать, в ущерб примитивности (которое есть не только основное достоинство ii, но и вообще причина существования ii). Но бить по самому смыслу ii, и не обращаь на это внимание, сужая те целевые группы, для которых он был изобретён, и при этом пытаясь преикрутить его туда, где его возможности вообще малозначимы, и где гораздо эффективнее изобрести более уместное для этого средство - это просто следствие вопиющей некомпетентности, связанное с уже указанными мною причинами, вечному хватанию "вершков" и основе решений не на анализе, а на обрывочных аналогиях, которые превращаются в догмы ("в подобной ситуации поступать всегда вот так, и никак иначе". не люди, а триггеры).

И объяснять вот это постоянно мне уже сильно надоело.

Надоело препираться не по делу. Есть /u/ и я его поддерживаю. И буду поддерживать /list.txt и /blacklist.txt. За остальные расширения мне никто так и не пояснил чем они так примечательны =)

P.S.: Вот новый скрин с почти готовой читалкой http://spline.rooker.ru/screen_20140805.png Осталось только unixtime привести в нормальное состояние и прокрутку сообщений сделать.

Рома, всё просто. Вместо ясного и чёткого описания ты каждый раз пускаешься в одни и те же пространные рассуждения с дудочками, кувшинчиками и прочими дискетами. Не дети интернета плохи, плохо общество, которое таких уникумов воспитывает. ii в моём понимании это /u/. Ну, возможно ещё всё таки /list.txt и чёрный список. Всё остальное как не существует на твоей ноде для простых смертных, так и у нас отсутствует.

Про андроид клиент хочется заметить что андроид это лютый зоопарк и гарантировать работу одной и той же софтины на девайсов разных производителей просто невозможно. И нода тут совершенно ни при чём. На ней никуда не делись ни /u/ в самом что ни на есть классическом понимании ни даже /m и /e. И то что очередной китайфон (а других телефонов с андроидами можно считать что и нет) отказался адекватно исполнять программу это проблема китайфона. Значит надо ориентироваться на iOS чтоб не было потом из-за вендоров обвинений в несовместимости на нодах.

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

> И да. Я прекрасно понимаю что ты тут объясняешь, но реально /x/ ничем не отличается от твоих спрятанных ключей. Совсем. Только лишним запросом, но это частности и к вопросу совместимости отношения не имеют.

Я. Уже. Объяснил. Чем. Они. Отличаются.

Тем, что приделываются за 3 минуты, без переделки стандартов, без лишних вопросов. А потом спокойно проверяются на практике. И выносится суждение, нужны они или нет.

Так было всегда, до тех пор, пока сеть не наводнили реформаторы.

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


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

>Надоело препираться не по делу.
Это точно

> Есть /u/ и я его поддерживаю. И буду поддерживать /list.txt и /blacklist.txt. За остальные расширения мне никто так и не пояснил чем они так примечательны =)
Ну и ладно. А я уже для себя решил, что делаю свой форк клиента (в перспективе свой клиент), чтобы иметь нужное и не иметь ненужное :)

>P.S.: Вот новый скрин с почти готовой читалкой http://spline.rooker.ru/screen_20140805.png
Хорошо выглядит. Ждём.