Там небольшой косяк с грамматикой в настройках, поправлю в следующем билде

Как там правильно вбить урлы сервера и списка эх?

В общем, я решил, что нам это нужно. В качестве api лучше взять /x/echolist (u/трогать не надо). Эхи надо будет добавлять туда вручную: не обязательно бонные, а любые, которые вообще есть.

В адрес прописываешь http://irk38.tk/ii/ii-point.php?q=/u/
В Auth-токен свой ключ

Далее либо во вкладке "Подписки" сам вводишь имена эх, которые тебя интересуют (и которые будут выводиться слева), либо прописываешь в "Общих настройках" третью строчку (адрес URL со списком эх) http://irk38.tk/ii/echo

Без лишних пробелов, разумеется:)

/u/ я лишь в качестве примера написал:)

ну да, там выводить основные эхи, чтобы было с чего начать

Заработало :)

Пишу с телефона.

Мои поздравления:) Как полет?

Надо добавить время к сообщениям. Без него не так прикольно.
Еще бы было хорошо сортировку по тредам прикрутить :)

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

а можно нормальную страницу с нормальным урлом, чтобы всегда новую версию можно было найти, сделать?

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

Ссылка не меняется, я заменяю файл на Яндекс.диске.
У меня нет аккаунта разработчика в гуглплее, так бы туда выложил и клиент бы сам обновлялся

В общем, сейчас я расскажу, как всё это было.

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

Поэтому я решил оставить так:

/m и /e - есть всегда, это основа, собственно сети - для разных sh-скриптов, для мелкой обработки, для кормления напрямую в js и так далее (возможно, надо бы и json/jsonp сделать, но я его, наоборот, убрал. возможно, в свою реализацию и верну :).

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

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

для odii у меня будут свой клиент и свой сервер, там у меня есть и list.txt и блеклист и прочее, если хочешь - сделай и поддержку odii (но там будут не только сообщения, это распредпортал :), можно ли это всё всунуть в андроид-клиент - я не знаю. у тебя там plain-text? а то я ещё не решил, каким форматом форматировать текст, если твоему клиенту интересно - давай исходить из его текущих возможностей).

хотелось бы простой http-ссылки.

кстати, есть же всякие f-droid - туда мож положить?

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

в общем, по возможности буду перекладывать на http://apk.51t.ru

вдруг самому понадобятся :)

Не вижу в проприетарности гуглплея ничего плохого)

Исходники будут после рефакторинга кода, выкладывать в текущем не вижу смысла

>Гугл плей проприетарный и от гугла.
Зато там пользователей очень много. Можно скинуться и купить аккаунт.

>Используйте свободные магазины приложений типо F-Droid.
А это можно вместе с гуглоплеем сделать.

>И да, лучше выложить исходники.
Поддерживаю.

> Не вижу в проприетарности гуглплея ничего плохого)
Видимо, меня одного тут Столлман покусал? =)

Меня Столлман не кусал, но проприетарность - это плохо, причём однозначно. Конечно, если думать не только о сегодняшнем дне, а хоть чуть-чуть вперёд. Если не думать, то http://nz.51t.ru/1Cor.15:32 :)

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

можно сделать банально /x/api , которая вернет, например:
/e
/m
/u

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

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

Ломать ничего не надо, но добавить возможность сообщать какие протоколы сервер поддерживает имхо надо

Я просто к этому спокойно отношусь )

Ты имеешь ввиду прямую ссылку на apk? Посмотрю что можно сделать.

В F-Droid надо выкладывать с сорцами насколько я знаю. Как будут в опрятном виде - выложу.

Кому как, для себя я даже в самой дальней перспективе не вижу ничего плохого. Мне ехать, а не шашечки:)

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

Свобода - это не шашечки.

Весь вопрос идёт от непонимания "откуда берутся программы". :) Кто их пишет ДЛЯ ТЕБЯ, и зачем. Почему такой порядок вещей, а не иной. Могло бы быть лучше, или хуже? И что ты МОЖЕШЬ сделать, а что НЕ МОЖЕШЬ.

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

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

> В этих данных клиент ищет знакомое для себя апи и использует его.

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

и чтобы эталонную реализацию можно было объяснить на пальцах, при минимальном количестве вилок "или/или".

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

два запроса сложнее одного :) официальный клиент keep-alive не умеет :) а преимущество - сомнительно. как и сама фича таймстампов.

да просто проверяй на наличие /x/ и всё. либо один раз, либо раз в сутки, либо при каждом коннекте. или, как это задавалось у меня - схемой... http://XXXX.ru/u/ - это одно. xxxx.ru/z/ - это другое. от последних трёх символов зависит протокол - (как от первых с :// - протокол доставки).

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

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

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

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

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

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

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

Вся простота разбивается о то, что теперь при каждом (!) обновлении списка сообщений мобильник должен выкачивать по 700+ хэшей сообщений. Зачем?

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

А наркоторговля - свобода жить хорошо. :)

Это "Теория пастбищ". Пока ты пасешься на чужом - ты сыт и доволен, и не думаешь, откуда берётся трава. Вот это то и оно, что ты не думаешь, откуда берётся трава. :) И на каких условиях. :)

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

Это вообще полная подмена понятий. И исхождение из неверных предпосылок. А в указанном случае - это вообще больше похоже на паразитирование "тут лишь бы лучше сейчас, там лишь бы лучше сейчас, а последствия меня не волнуют". Вообще, такие люди, если называть вещи своими именами - враги. Они, вместо того, чтобы поддерживать рост светлого будущего, тянут в тёмное прошлое. Да ещё снабжают тех, кто тянет, деньгами, ресурсами, юзербазой. Когда одни стригут лохов и у них сто тысяч миллиардов денег и ресурсов, а другие не стригут, и у них десять миллиардов - это неравный бой. Зато, если бы свободное отставало хотя бы в 1000 раз по ресурсам, оно бы на голову превосходило - это раз, и давало все преимущество свободного - это два. И когда одни делают так, чтобы было лучше всем, другие или равнодушно помогают врагам, или намеренно помогают врагам. А потом ещё говорят "а свободное хуже!". Это гениальное заявление. Типа, кто-то всю жизнь помогал деньгами, решениями и юзербазой проприетарному, вместе с другими, а сами ходят на Поле Чудес чтобы посмотреть "а как там выросло свободное?". Как будто оно само вырастет.

Впрочем, несмотря на всё перечисленное, свободные проекты за последние 10 лет преодолели огромное расстояние, тенденции у них гораздо лучше, чем у проприетарное. Да и выгоды, которые дают свободные программы, очевидны становятся многим. Поэтому некоторые проприетарщики будут просто вылетать из бизнеса. И вот когда они вылетят, а программу без исходников... впрочем, о чём я говорю, уже есть стон "моя любимая программа без XP не работает, в XP её никто не переписал, потому что автора нет, а другие не могут"... вот тогда многие подумают, зачем они ели зерно, предназначенное на посадку.... но будет уже поздно. :)

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

Всё правильно про проприетарщину сказал

> впрочем, о чём я говорю, уже есть стон "моя любимая программа без XP не работает, в XP её никто не переписал, потому что автора нет, а другие не могут"... вот тогда многие подумают, зачем они ели зерно, предназначенное на посадку.... но будет уже поздно. :)
У меня на сканер дрова только на ХР, дрова проприетарные, разработчик куда-то делись, код никто не поддерживает. Ни на новых версиях той же винды, ни на линуксах сканер не работает, а всё потому что драйвер-то проприетарный. Приходится держать виртуалку специально для этих нужд, что зачастую очень неудобно.

> это 15 кб без gzip, или 11 кб в gzip. это проблема?
Если куча подписок, то это, к примеру, 300 кб без gzip и 200 с gzip. На телефоне это очень большая проблема, тем более, по gprs. Даже если в эху никто не написал, всё равно приходится скачивать такие объёмы. Таймстампы очень сильно экономят трафик.

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

а подобные расширения, которые позволяли делать всякое - были, раньше. к счастью, их всех убили :) это отягощало описание api - сейчас я его могу в трамвае кому-нибудь рассказать на словах :), раньше - нет. оно не решает никаких проблем пользователей. оно заставит ВСЕ, КТО ХОЧЕТ БЫТЬ ОФНОДОЙ, повторять все эти вещи, иначе какой-нибудь клиент не будет работать.

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

ii против программистов! :) и технологичности :) потому что это всегда вырастает в овертехнологичность, фичи добавляются по "хочется добавить фичу", а не по нужде.

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

Да, это проблема. Опросить 10 эх и потерять 130 кб мобильного трафика? И уж конечно проще напрягать gc на телефоне, чем дать возможность нодам делать кастомные расширешия без ломания основного протокола.

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

Я напоминаю, речь идет о мобилках и планшетах.

Да какая офнода на телефоне, ты себе как это представляешь?

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

> Если куча подписок, то это, к примеру, 300 кб без gzip и 200 с gzip.

не могу спроецировать это на фидо. кроме как анекдотом про блондинку и голдед "а что, их читать надо? а я в нестеренкину игру Фидо играла, там сообщения сами читались".

если у тебя такое число подписок, то ты вообще не попадёшь в идентичные эхи, и у тебя ВСЕГДА будет два запроса вместо одного. если, конечно, ты не поллишь раз в 5 секунд, а сообщения не читаешь.

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

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

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

Мда, т.е. ты утверждаешь, что запрос вида:

/x/t/echo1/echo2/.../echo-n

который вернет n строк с версией базы
ВНЕЗАПНО не лучше чем постоянний поллинг?

Давай после этого прекратим обсуждать это. Идею я предложил не с потолка, она используется в Dns

Оффлайн кучей-файлов-на-карте убьет её. Имхо. Единственный нормальный вариант для меня - хранить в sqlite, которая крутится на каждом телефоне

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

чувак, ты не поверишь, но я читал сообщения с офноды, в офлайне, ещё тогда, когда она только появилась

через rss-клиент. причём тут вообще плейн-текст? кого волнует, в плейнтексте или нет хранится база? какое это вообще имеет значение.

> Да, это проблема. Опросить 10 эх и потерять 130 кб мобильного трафика?


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

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

а у меня, моя реализация, работает с первого раза, и БЕЗ ПРОБЛЕМ. и тот, кто будет это повторять, по правилам, у того тоже ПРОБЛЕМ НЕ БУДЕТ. вот это - важно. лишние 100 кб трафика (в день? в неделю? в месяц?) один фиг, это всё СОПУТСТВУЮЩИЙ трафик, и почти всегда соотношение этих списков к сообщениям будет примерно одинаковым ПРОЦЕНТОМ, если ты не делаешь полинг каждые две секунды. То есть, на X кб сообщений - Y% +- сопутствующего трафика. это вытекает из природы сети и правильной её организации. не нужно тут трясти чистыми процентами. ты ещё на html пожалуйся, что каждый раз, когда ты загружаешь текст, тебе ещё лишние тэги загружаются. или на rss, там тоже есть оверхед. это бред, и бред откровенный.

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

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

у нас уже были проблемы с отладкой сторонних вещей, когда плодятся неоднозначности. если добавлять к ним ещё проблемы - загребётесь всё отлаживать. цель именно сделать протокол простой, как палка. которым можно пользоваться. а не страдать от того, что там какие-то частные случаи не обрабатываются. и никогда не будут обрабатываться, потому что потенциальные проблемы - не нужны, реальных хватает. нужно делать всё хорошо и правильно с первого раза, чтобы и потом всегда всё работало. а не делать разные виды нод, где кто-то с кем-то совеместим, а кто-то - нет. совместимость и беспроблемность и очевидность ВАЖНЕЕ 130 кб СОПУТСТВУЮЩЕГО трафика.

> Мда, т.е. ты утверждаешь, что запрос вида:
> /x/t/echo1/echo2/.../echo-n
> который вернет n строк с версией базы
> ВНЕЗАПНО не лучше чем постоянний поллинг?

тебя бы в фидо часто били. по морде. за такие замашки.

или пойди на гитхаб, и сделай там постоянный поллинг хотя бы 5000 репозиториев

ты вообще понимаешь, что такое ФИДО? и почему на главной написано "помесь фидо и git"?

> Оффлайн кучей-файлов-на-карте убьет её. Имхо. Единственный нормальный вариант для меня - хранить в sqlite, которая крутится на каждом телефоне

разницы между кучей файлов и sqlite - для ноды ровно 0. для клиента ровно 0.

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

Разница в физическом способе хранения

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

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

> Разница в физическом способе хранения

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

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

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

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

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

в данном случае мне пришлось делать свою реализацию, потому что hg/git меня не удовлетворяла по одному-единственному параметру. по всем остальным - устраивала полностью, и если бы не он - взял бы её, а не делал ii.

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

это именно vcs. только с одним отличием - порядок следования списков.