 ping
II/IDEC networks :: idec.talks :: Сеть IDEC / feed
|
Contacts :: Login |
[>]
Re: Протокол IDEC
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 06:43:49
AL>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage> Несколько десятков ID и получит. Только новое.
Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?
mirage> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage> И получает ID4 ID5 ID6 и запоминает ID6.
mirage> Весь индекс тянуть заново не надо.
Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 06:43:49
AL>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage> Несколько десятков ID и получит. Только новое.
Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?
mirage> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage> И получает ID4 ID5 ID6 и запоминает ID6.
mirage> Весь индекс тянуть заново не надо.
Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: Протокол IDEC
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 06:43:49
mirage> Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.
Как ты это видишь в текущем варианте? Как из ID получить что-то типа -10:10?
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 06:43:49
mirage> Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.
Как ты это видишь в текущем варианте? Как из ID получить что-то типа -10:10?
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: Протокол IDEC
idec.talks
Andrew Lobanov(tavern,1) — Peter
2018-10-10 06:43:50
>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — Peter
2018-10-10 06:43:50
>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: Caesium и файлэхи
idec.talks
mirage(syscall,44) — mirage
2018-10-10 06:48:47
Peter>> Фехи не поддерживаются этой нодой (syscall) :)
mirage> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
Кажется я доменом ошибся. В одной доке .tk в другой .ml
В итоге в клиенте одно, в браузере другое :)
+++ Caesium/0.4 RC1
idec.talks
mirage(syscall,44) — mirage
2018-10-10 06:48:47
Peter>> Фехи не поддерживаются этой нодой (syscall) :)
mirage> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
Кажется я доменом ошибся. В одной доке .tk в другой .ml
В итоге в клиенте одно, в браузере другое :)
+++ Caesium/0.4 RC1
[>]
Re: Протокол IDEC
idec.talks
mirage(syscall,44) — Andrew Lobanov
2018-10-10 07:01:48
AL>>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage>> Несколько десятков ID и получит. Только новое.
AL> Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?
Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Допустим это 100 idшников.
Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
1. Придет меньше 100 id - запоминаем последний, конец.
2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.
mirage>> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage>> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage>> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage>> И получает ID4 ID5 ID6 и запоминает ID6.
mirage>> Весь индекс тянуть заново не надо.
AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.
+++ Caesium/0.4 RC1
idec.talks
mirage(syscall,44) — Andrew Lobanov
2018-10-10 07:01:48
AL>>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage>> Несколько десятков ID и получит. Только новое.
AL> Каким образом фетчер узнает по одному ID сколько ему сообщений зпрашивать в слайсе? Вот он запомнил, что поледним получил сообщение mzu2V8Iz3VIAVeDg0TOi. Как он узнает сколько именно тянуть?
Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Допустим это 100 idшников.
Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
1. Придет меньше 100 id - запоминаем последний, конец.
2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.
mirage>> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage>> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage>> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage>> И получает ID4 ID5 ID6 и запоминает ID6.
mirage>> Весь индекс тянуть заново не надо.
AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.
+++ Caesium/0.4 RC1
[>]
Re: Протокол IDEC
idec.talks
mirage(syscall,44) — Andrew Lobanov
2018-10-10 07:01:49
>>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter>> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
AL> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах
и время обработки запроса. С ID проще, строже.
+++ Caesium/0.4 RC1
idec.talks
mirage(syscall,44) — Andrew Lobanov
2018-10-10 07:01:49
>>> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Peter>> Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
AL> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах
и время обработки запроса. С ID проще, строже.
+++ Caesium/0.4 RC1
[>]
Re: Протокол IDEC
idec.talks
mirage(syscall,44) — Andrew Lobanov
2018-10-10 07:15:44
AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
По нетмайлу готов proposal. Просто чтобы внимание не распылять по одной теме пишу :)
+++ Caesium/0.4 RC1
idec.talks
mirage(syscall,44) — Andrew Lobanov
2018-10-10 07:15:44
AL> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
По нетмайлу готов proposal. Просто чтобы внимание не распылять по одной теме пишу :)
+++ Caesium/0.4 RC1
[>]
Re: Протокол IDEC
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 07:23:33
mirage> Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Сколько угодно =)
mirage> Допустим это 100 idшников.
mirage> Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
mirage> 1. Придет меньше 100 id - запоминаем последний, конец.
mirage> 2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.
Этот вариант мы тоже рассматривали. Но пока думали как это сделать так, чтобы не плодить сущностей и не сломать совместимость с ii (ты до сих пор можешь взять ii-client-03 и пользоваться им), соорудили эту штуку на том, что было. Получилось просто и без излишеств.
AL>> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
mirage> Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.
Я понимаю, что предложение, но не понимаю в чём будет выигрыш? Можно и аутбаунды сделать а-ля FTN, но пользы нет.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 07:23:33
mirage> Фетчер знает сколько ему надо максимум запросить чтобы не подавиться, по каким-либо причинам.
Сколько угодно =)
mirage> Допустим это 100 idшников.
mirage> Он запрашивает 100 записей от последнего id. В итоге будет 2 случая:
mirage> 1. Придет меньше 100 id - запоминаем последний, конец.
mirage> 2. Придет 100 id - запоминаем последний и запрашиваем снова 100 от него.
Этот вариант мы тоже рассматривали. Но пока думали как это сделать так, чтобы не плодить сущностей и не сломать совместимость с ii (ты до сих пор можешь взять ii-client-03 и пользоваться им), соорудили эту штуку на том, что было. Получилось просто и без излишеств.
AL>> Это будет уже совсем другой набор договорённостей. Можно придумать что угодно, но есть такая вещь, как совместимость. В любом случае, преимуществ такого подхода пока не видно. Куда нужнее личная переписка КМК.
mirage> Это было предложение на вопрос в дискуссии о не совсем ясном числе в ответе API. Ну и это может быть расширением.
Я понимаю, что предложение, но не понимаю в чём будет выигрыш? Можно и аутбаунды сделать а-ля FTN, но пользы нет.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: Протокол IDEC
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 07:23:33
AL>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
Ещё проще так, как есть. Потому что оно уже есть и оно простое.
Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 07:23:33
AL>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
Ещё проще так, как есть. Потому что оно уже есть и оно простое.
Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: Caesium и файлэхи
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 07:23:34
Peter>>> Фехи не поддерживаются этой нодой (syscall) :)
mirage>> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
mirage> Кажется я доменом ошибся. В одной доке .tk в другой .ml
mirage> В итоге в клиенте одно, в браузере другое :)
Да. tk я проморгал =(
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 07:23:34
Peter>>> Фехи не поддерживаются этой нодой (syscall) :)
mirage>> Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
mirage> Кажется я доменом ошибся. В одной доке .tk в другой .ml
mirage> В итоге в клиенте одно, в браузере другое :)
Да. tk я проморгал =(
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: Протокол IDEC
idec.talks
mirage(syscall,44) — Andrew Lobanov
2018-10-10 08:08:56
AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
Решаемая задача: скачать обновление индекса.
Предложеное решение: запросить все что после конкретного ID.
Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
Получается, если надо качать все обновление индекса за раз, то один запрос.
+++ Caesium/0.4 RC1
idec.talks
mirage(syscall,44) — Andrew Lobanov
2018-10-10 08:08:56
AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
Решаемая задача: скачать обновление индекса.
Предложеное решение: запросить все что после конкретного ID.
Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
Получается, если надо качать все обновление индекса за раз, то один запрос.
+++ Caesium/0.4 RC1
[>]
Re: Протокол IDEC
idec.talks
mirage(syscall,44) — Andrew Lobanov
2018-10-10 08:19:48
AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
Этот x/c нужен же для u/e?
Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.
+++ Caesium/0.4 RC1
idec.talks
mirage(syscall,44) — Andrew Lobanov
2018-10-10 08:19:48
AL>>> Тоже кривое решение как мне видится. Если порыться в архивах, то можно найти конкретные примеры потерь сообщений.
mirage>> Тут много вопросов о том кто какое время берет и с каким сравнивает, как влияет на это разница во времени на нодах и время обработки запроса. С ID проще, строже.
AL> Ещё проще так, как есть. Потому что оно уже есть и оно простое.
AL> Берём x/c по конференциям в подписке, сраниваем со старыми значениями с прошлой сессии, считаем максимальную разницу и одним запросом забираем индекс одним запросом. То есть два запроса на определение индекса при любом объёме новых сообщений.
Этот x/c нужен же для u/e?
Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.
+++ Caesium/0.4 RC1
[>]
Re: Протокол IDEC
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 08:51:37
mirage> Решаемая задача: скачать обновление индекса.
mirage> Предложеное решение: запросить все что после конкретного ID.
mirage> Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
mirage> Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
mirage> Получается, если надо качать все обновление индекса за раз, то один запрос.
Можешь предложить красивое решение?
Вот, например, я подписан на несколько эх. Тогда я просто отправляю запрос x/c/bash.rss/pipe.2032/idec.talks и потом делаю u/e/bash.rss/pipe.2032/idec.talks/-50:50. Передавать что-то типа x/e/bash.rss/<id1>/pipe.2032/<id2>/idec.talks/<id3>?
Я ничего не вижу плохого в более других вариантах, если это будет нужно кому-то. Но пока я не вижу кому и зачем может быть нужно то, что ты предлагаешь. Какую практическую проблему ты пыташься решить?
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 08:51:37
mirage> Решаемая задача: скачать обновление индекса.
mirage> Предложеное решение: запросить все что после конкретного ID.
mirage> Я не понял зачем ты спросил в этом случае про слайсы, они тут не нужны.
mirage> Я подумал слайсы нужны что бы скачивать обновление индекса по частям, если например есть опасения в слишком большом обновлении индекса.
mirage> Получается, если надо качать все обновление индекса за раз, то один запрос.
Можешь предложить красивое решение?
Вот, например, я подписан на несколько эх. Тогда я просто отправляю запрос x/c/bash.rss/pipe.2032/idec.talks и потом делаю u/e/bash.rss/pipe.2032/idec.talks/-50:50. Передавать что-то типа x/e/bash.rss/<id1>/pipe.2032/<id2>/idec.talks/<id3>?
Я ничего не вижу плохого в более других вариантах, если это будет нужно кому-то. Но пока я не вижу кому и зачем может быть нужно то, что ты предлагаешь. Какую практическую проблему ты пыташься решить?
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: Протокол IDEC
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 08:51:38
mirage> Этот x/c нужен же для u/e?
Нет.
mirage> Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
mirage> Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
Да, но зато никакой дополнительной нагрузки на ноду.
mirage> А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.
Несколько килобайт (это в худшем случае) лишней информации без переписывания ноды. И узлу не придётся шерстить толстые инндексы на каждый чих.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-10 08:51:38
mirage> Этот x/c нужен же для u/e?
Нет.
mirage> Смотрю в описание u/e: смещение указывается одно для всех эх в запросе?
mirage> Получается не оптимально. Ведь в разных эхах разное количество апдейтов.
Да, но зато никакой дополнительной нагрузки на ноду.
mirage> А вот например эхаA:idA/эхаB:idB/.... будет оптимальнее.
Несколько килобайт (это в худшем случае) лишней информации без переписывания ноды. И узлу не придётся шерстить толстые инндексы на каждый чих.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Кто какой софт для ноды использует?
idec.talks
mirage(syscall,44) — All
2018-10-11 15:14:58
Сабж.
+++ Caesium/0.4 RC1
idec.talks
mirage(syscall,44) — All
2018-10-11 15:14:58
Сабж.
+++ Caesium/0.4 RC1
[>]
Re: Кто какой софт для ноды использует?
idec.talks
Peter(syscall,1) — mirage
2018-10-11 16:12:55
> Кто какой софт для ноды использует?
Я на https://github.com/gl00my/iing
Это запатченный на мои нужды iing.
idec.talks
Peter(syscall,1) — mirage
2018-10-11 16:12:55
> Кто какой софт для ноды использует?
Я на https://github.com/gl00my/iing
Это запатченный на мои нужды iing.
[>]
Re: Кто какой софт для ноды использует?
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-11 18:21:55
mirage> Сабж.
В данный момент это iing, но в планах переход на новый софт, который у меня подвис в процессе и будет релизнут, видимо, уже только в следующем году. Он готов, но ещё не доделан вебинтерфейс. На этот раз на golang =)
+++ Caesium/0.4 RC1
idec.talks
Andrew Lobanov(tavern,1) — mirage
2018-10-11 18:21:55
mirage> Сабж.
В данный момент это iing, но в планах переход на новый софт, который у меня подвис в процессе и будет релизнут, видимо, уже только в следующем году. Он готов, но ещё не доделан вебинтерфейс. На этот раз на golang =)
+++ Caesium/0.4 RC1
[>]
Re: Кто какой софт для ноды использует?
idec.talks
vit01(mira, 1) — mirage
2018-10-11 18:28:17
Андрей пользует собственный iing
Пётр - патченный iing
У меня своя нода ii-php
У Дениса своя реализация на базе elasticsearch
По сути единой эталонной серверной части у нас нет, каждый пишет её себе сам. Во-первых, свой код проще писать, чем читать чужой. Во-вторых, простота протокола позволяет такую роскошь как "а лучше свою напишу"
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
idec.talks
vit01(mira, 1) — mirage
2018-10-11 18:28:17
Андрей пользует собственный iing
Пётр - патченный iing
У меня своя нода ii-php
У Дениса своя реализация на базе elasticsearch
По сути единой эталонной серверной части у нас нет, каждый пишет её себе сам. Во-первых, свой код проще писать, чем читать чужой. Во-вторых, простота протокола позволяет такую роскошь как "а лучше свою напишу"
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: Протокол IDEC
idec.talks
vit01(mira, 1) — mirage
2018-10-11 18:44:25
vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage> Тогда это уже не количество сообщений будет, а что-то другое.
Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage> Только возникнет проблема если это сообщение будет удалено.
Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
idec.talks
vit01(mira, 1) — mirage
2018-10-11 18:44:25
vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage> Тогда это уже не количество сообщений будет, а что-то другое.
Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage> Только возникнет проблема если это сообщение будет удалено.
Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: Протокол IDEC
idec.talks
Andrew Lobanov(tavern,1) — vit01
2018-10-12 12:06:30
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
vit01> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.
mirage>> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
vit01> Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
vit01> iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
vit01> Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически.
Да все эти варианты мы уже рассматривали и обсуждали. Начиная с лета 2014 и заканчивая обсуждением расширенной u/e. Пройденный этап, откинутые варианты. Нет смысла к ним возвращаться. К тому же до сих пор не было озвучено предполагаемых преимуществ перед текущим вариантом.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — vit01
2018-10-12 12:06:30
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
vit01> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.
mirage>> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
vit01> Дефолт для клиентов - скачивать по 20 сообщений за раз (можно увеличить в настройках), а индекс получать пачками.
vit01> iitxt медленный, потому что он хитро парсит сообщения и что-то пересчитывает, это к автору клиента вопрос.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
vit01> Проблема не только в удалении, но и в том, что сообщения могут не сохранять порядок в индексе базы. То есть они могут быть перепутаны хронологически.
Да все эти варианты мы уже рассматривали и обсуждали. Начиная с лета 2014 и заканчивая обсуждением расширенной u/e. Пройденный этап, откинутые варианты. Нет смысла к ним возвращаться. К тому же до сих пор не было озвучено предполагаемых преимуществ перед текущим вариантом.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: Протокол IDEC
idec.talks
vit01(mira, 1) — Andrew Lobanov
2018-10-12 15:18:49
vit01>>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
vit01>> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
AL> Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.
Действительно, тут я ошибся. IDEC Mobile тоже подсчитывает слайсы по ним (хоть и более хитро), а ещё уведомления выдаёт :)
Важно, что поле только возрастает, и что на сервере после удаления сообщений значение /x/c не должно уменьшаться.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
idec.talks
vit01(mira, 1) — Andrew Lobanov
2018-10-12 15:18:49
vit01>>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
vit01>> Надо поправить в документации, чтобы не заводить путаницу. Но в первом приближении это обычно и есть количество сообщений. Можно timestamp новейшего сообщения в эхе подставлять, наши клиенты этот вариант съедят даже без переписывания кода.
AL> Ваши съедят, а мои подавятся. На базе x/c мои фетчеры вычисляют размер слайса.
Действительно, тут я ошибся. IDEC Mobile тоже подсчитывает слайсы по ним (хоть и более хитро), а ещё уведомления выдаёт :)
Важно, что поле только возрастает, и что на сервере после удаления сообщений значение /x/c не должно уменьшаться.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Кривой файл
idec.talks
Andrew Lobanov(tavern,1) — All
2018-10-22 05:39:43
Возможно вчера успел утечь в фэху music сабж. bitjam_021 без расширения. Просьба сисопов проверить свои узлы в случае подписки на эту фэху.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — All
2018-10-22 05:39:43
Возможно вчера успел утечь в фэху music сабж. bitjam_021 без расширения. Просьба сисопов проверить свои узлы в случае подписки на эту фэху.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: Кривой файл
idec.talks
vit01(mira, 1) — Andrew Lobanov
2018-10-22 12:58:36
AL> Возможно вчера успел утечь в фэху music сабж. bitjam_021 без расширения. Просьба сисопов проверить свои узлы в случае подписки на эту фэху.
Сначала удалил файл зиповник, а потом только увидел, что "без расширения". Скачал обратно :)
Ты предупреждай, когда большие файлы кидаешь. У меня на фетчере лимит то 30 мегабайт, то 35 на файл.
Поэтому, чтобы *все* твои файлы "доходили до адресата", мне приходится править конфиг, увеличивая лимит, потом вручную дёрнуть фетчер и править конфиг обратно.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
idec.talks
vit01(mira, 1) — Andrew Lobanov
2018-10-22 12:58:36
AL> Возможно вчера успел утечь в фэху music сабж. bitjam_021 без расширения. Просьба сисопов проверить свои узлы в случае подписки на эту фэху.
Сначала удалил файл зиповник, а потом только увидел, что "без расширения". Скачал обратно :)
Ты предупреждай, когда большие файлы кидаешь. У меня на фетчере лимит то 30 мегабайт, то 35 на файл.
Поэтому, чтобы *все* твои файлы "доходили до адресата", мне приходится править конфиг, увеличивая лимит, потом вручную дёрнуть фетчер и править конфиг обратно.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: Кривой файл
idec.talks
Andrew Lobanov(tavern,1) — vit01
2018-10-22 15:59:48
AL>> Возможно вчера успел утечь в фэху music сабж. bitjam_021 без расширения. Просьба сисопов проверить свои узлы в случае подписки на эту фэху.
vit01> Сначала удалил файл зиповник, а потом только увидел, что "без расширения". Скачал обратно :)
vit01> Ты предупреждай, когда большие файлы кидаешь. У меня на фетчере лимит то 30 мегабайт, то 35 на файл.
vit01> Поэтому, чтобы *все* твои файлы "доходили до адресата", мне приходится править конфиг, увеличивая лимит, потом вручную дёрнуть фетчер и править конфиг обратно.
Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)
Ладно. Буду в музыкальные эхи анонсить.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — vit01
2018-10-22 15:59:48
AL>> Возможно вчера успел утечь в фэху music сабж. bitjam_021 без расширения. Просьба сисопов проверить свои узлы в случае подписки на эту фэху.
vit01> Сначала удалил файл зиповник, а потом только увидел, что "без расширения". Скачал обратно :)
vit01> Ты предупреждай, когда большие файлы кидаешь. У меня на фетчере лимит то 30 мегабайт, то 35 на файл.
vit01> Поэтому, чтобы *все* твои файлы "доходили до адресата", мне приходится править конфиг, увеличивая лимит, потом вручную дёрнуть фетчер и править конфиг обратно.
Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)
Ладно. Буду в музыкальные эхи анонсить.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: Кривой файл
idec.talks
vit01(mira, 1) — Andrew Lobanov
2018-10-24 16:27:43
AL> Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)
AL> Ладно. Буду в музыкальные эхи анонсить.
Увеличил до 80 мб лимит. Пока место на диске позволяет.
Но файлы по-хорошему анонсировать всё равно надо. Во-первых, не все следят за файлэхами. Во-вторых, чтобы не скачивать котов в мешке, ведь иногда описания может быть недостаточно.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
idec.talks
vit01(mira, 1) — Andrew Lobanov
2018-10-24 16:27:43
AL> Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)
AL> Ладно. Буду в музыкальные эхи анонсить.
Увеличил до 80 мб лимит. Пока место на диске позволяет.
Но файлы по-хорошему анонсировать всё равно надо. Во-первых, не все следят за файлэхами. Во-вторых, чтобы не скачивать котов в мешке, ведь иногда описания может быть недостаточно.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: Кривой файл
idec.talks
Andrew Lobanov(tavern,1) — vit01
2018-10-24 16:51:41
AL>> Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)
AL>> Ладно. Буду в музыкальные эхи анонсить.
vit01> Увеличил до 80 мб лимит. Пока место на диске позволяет.
vit01> Но файлы по-хорошему анонсировать всё равно надо. Во-первых, не все следят за файлэхами. Во-вторых, чтобы не скачивать котов в мешке, ведь иногда описания может быть недостаточно.
Ну вообще, bitjam podcast он и есть bitjam podcast =)
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
idec.talks
Andrew Lobanov(tavern,1) — vit01
2018-10-24 16:51:41
AL>> Ну я ж не знал, что лимит такой небольшой. Я файлы меньше 100 Мб кидаю. Зато почти каждый день =)
AL>> Ладно. Буду в музыкальные эхи анонсить.
vit01> Увеличил до 80 мб лимит. Пока место на диске позволяет.
vit01> Но файлы по-хорошему анонсировать всё равно надо. Во-первых, не все следят за файлэхами. Во-вторых, чтобы не скачивать котов в мешке, ведь иногда описания может быть недостаточно.
Ну вообще, bitjam podcast он и есть bitjam podcast =)
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: dynamic
idec.talks
vit01(mira, 1) — Difrex
2018-11-01 16:37:16
Difrex> // А я на динамик новый дизайн завез. Думаю допилить его(постинг) наконец-то и выложить сорцы
Как раз заходил туда сегодня, чтобы глянуть статистику по эхам. Правда, чего нужно, не нашёл
Хотелось посмотреть поток сообщений в "роботизированных" эхах по дням недели в среднем за месяц, а там только для "человеческих"
Можешь пожалуйста сделать похожую страничку со статистикой для новостных эх? Ну или хотя бы подсказку дать насчёт API Elasticsearch, чтобы вытащить данные.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
idec.talks
vit01(mira, 1) — Difrex
2018-11-01 16:37:16
Difrex> // А я на динамик новый дизайн завез. Думаю допилить его(постинг) наконец-то и выложить сорцы
Как раз заходил туда сегодня, чтобы глянуть статистику по эхам. Правда, чего нужно, не нашёл
Хотелось посмотреть поток сообщений в "роботизированных" эхах по дням недели в среднем за месяц, а там только для "человеческих"
Можешь пожалуйста сделать похожую страничку со статистикой для новостных эх? Ну или хотя бы подсказку дать насчёт API Elasticsearch, чтобы вытащить данные.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: dynamic
idec.talks
Difrex(tavern,23) — vit01
2018-11-01 16:55:46
vit01> Как раз заходил туда сегодня, чтобы глянуть статистику по эхам. Правда, чего нужно, не нашёл
vit01> Хотелось посмотреть поток сообщений в "роботизированных" эхах по дням недели в среднем за месяц, а там только для "человеческих"
Вот этого через АПИ не получишь - наружу не торчит, т.к. для статов по дням недели используется groovy,
а это потенциальная уязвимость.
vit01> Можешь пожалуйста сделать похожую страничку со статистикой для новостных эх? Ну или хотя бы подсказку дать насчёт API Elasticsearch, чтобы вытащить данные.
Сделаю страничку для роботов :)
Еще есть в планах доливать раз в неделю данные в read-only индекс и прямо вставлять iframe из кибаны,
чтобы все интерактивно было.
vit01> +++ Отправлено через IDEC Mobile
vit01> +++ GNU/Linux, Android, physics, MLP:FIM
+++ Емакс не пищит и текст не портит
idec.talks
Difrex(tavern,23) — vit01
2018-11-01 16:55:46
vit01> Как раз заходил туда сегодня, чтобы глянуть статистику по эхам. Правда, чего нужно, не нашёл
vit01> Хотелось посмотреть поток сообщений в "роботизированных" эхах по дням недели в среднем за месяц, а там только для "человеческих"
Вот этого через АПИ не получишь - наружу не торчит, т.к. для статов по дням недели используется groovy,
а это потенциальная уязвимость.
vit01> Можешь пожалуйста сделать похожую страничку со статистикой для новостных эх? Ну или хотя бы подсказку дать насчёт API Elasticsearch, чтобы вытащить данные.
Сделаю страничку для роботов :)
Еще есть в планах доливать раз в неделю данные в read-only индекс и прямо вставлять iframe из кибаны,
чтобы все интерактивно было.
vit01> +++ Отправлено через IDEC Mobile
vit01> +++ GNU/Linux, Android, physics, MLP:FIM
+++ Емакс не пищит и текст не портит
[>]
Как взять на карандаш
idec.talks
Anotheroneuser(syscall,27) — All
2018-11-01 18:29:57
Ну или на перо. Наверняка кто-то уже задавал такой вопрос, но, простите меня, не углублялся в поиск.
Короче, ситуация такова. Я в последнее время занят и поэтому захожу только читать.
Отвечать сразу не хочу, потому что выходит полный бред (если отвечать не сразу, то выходит неполный). Но не знаю, как мне запомнить место, где было сообщение, на которое я хочу ответить. Понял, что почти не ориентируюсь в IDEC. И это огорчает.
Нельзя ли мне какую-нибудь схему.. или ссылку на объяснение-для-лиц-далёких-от?
А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.
idec.talks
Anotheroneuser(syscall,27) — All
2018-11-01 18:29:57
Ну или на перо. Наверняка кто-то уже задавал такой вопрос, но, простите меня, не углублялся в поиск.
Короче, ситуация такова. Я в последнее время занят и поэтому захожу только читать.
Отвечать сразу не хочу, потому что выходит полный бред (если отвечать не сразу, то выходит неполный). Но не знаю, как мне запомнить место, где было сообщение, на которое я хочу ответить. Понял, что почти не ориентируюсь в IDEC. И это огорчает.
Нельзя ли мне какую-нибудь схему.. или ссылку на объяснение-для-лиц-далёких-от?
А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.
[>]
Re: Как взять на карандаш
idec.talks
Peter(syscall,1) — Anotheroneuser
2018-11-01 19:21:05
> А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.
Я бы тоже хотел такую штуку, но сейчас она на syscall только для админа. Это те самые избранные сообщения.
В Android клиенте, наверное, есть.
А так - нажать на "глаз" над сообщением и скопировать куда то себе в редактор. :)
idec.talks
Peter(syscall,1) — Anotheroneuser
2018-11-01 19:21:05
> А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.
Я бы тоже хотел такую штуку, но сейчас она на syscall только для админа. Это те самые избранные сообщения.
В Android клиенте, наверное, есть.
А так - нажать на "глаз" над сообщением и скопировать куда то себе в редактор. :)
[>]
Re: Как взять на карандаш
idec.talks
Anotheroneuser(syscall,27) — Peter
2018-11-01 19:30:17
> нажать на "глаз" над сообщением и скопировать
О, нормально. Вполне подойдёт.
То есть, каждое сообщение здесь имеет собственный адрес, который никогда не поменяется?
idec.talks
Anotheroneuser(syscall,27) — Peter
2018-11-01 19:30:17
> нажать на "глаз" над сообщением и скопировать
О, нормально. Вполне подойдёт.
То есть, каждое сообщение здесь имеет собственный адрес, который никогда не поменяется?
[>]
Re: Как взять на карандаш
idec.talks
Peter(syscall,1) — Anotheroneuser
2018-11-01 19:55:42
Anotheroneuser> О, нормально. Вполне подойдёт.
Anotheroneuser> То есть, каждое сообщение здесь имеет собственный адрес, который никогда не поменяется?
Совершенно точно. Более того, это сообщение можно на любой ноде найти по этому хешу.
idec.talks
Peter(syscall,1) — Anotheroneuser
2018-11-01 19:55:42
Anotheroneuser> О, нормально. Вполне подойдёт.
Anotheroneuser> То есть, каждое сообщение здесь имеет собственный адрес, который никогда не поменяется?
Совершенно точно. Более того, это сообщение можно на любой ноде найти по этому хешу.
[>]
Re: Как взять на карандаш
idec.talks
vit01(mira, 1) — Anotheroneuser
2018-11-02 01:11:03
Anotheroneuser> Но не знаю, как мне запомнить место, где было сообщение, на которое я хочу ответить.
Anotheroneuser> А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.
1. Если нужно просто "сохранить на потом", то в IDEC Mobile жмёшь звёздочку в верхней панели, когда читаешь сообщение, и оно появится в избранных.
В CutieFeed есть аналогичная звёздочка.
Если сообщение в избранных больше не нужно (например, ты ответил уже на него), то убираешь звёздочку.
2. Если нужна ссылка на сообщение, то тебе нужен его уникальный ID, состоящий из 20 символов.
В IDEC Mobile он находится снизу темы сообщения, прямо под отправителем и получателем. Отображается как "msgid: blablabla"
Достаточно просто коротко тапнуть на надпись "msgid", и этот айдишник скопируется в буфер обмена.
В CutieFeed msgid тоже отображается, его можно выделить и скопировать.
3. Для IDEC Mobile есть и третий вариант. Наверху справа в верхней панели есть кнопка с тремя точками, где меню. В меню есть пункт "сохранить в файл".
Сообщение вместе с айдишником сохраняется в текстовый файл. Тоже полезно.
Также в этой менюшке есть пункт "поделиться", который делает похожую вещь. msgid в тексте сообщения тоже сохраняется
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
idec.talks
vit01(mira, 1) — Anotheroneuser
2018-11-02 01:11:03
Anotheroneuser> Но не знаю, как мне запомнить место, где было сообщение, на которое я хочу ответить.
Anotheroneuser> А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.
1. Если нужно просто "сохранить на потом", то в IDEC Mobile жмёшь звёздочку в верхней панели, когда читаешь сообщение, и оно появится в избранных.
В CutieFeed есть аналогичная звёздочка.
Если сообщение в избранных больше не нужно (например, ты ответил уже на него), то убираешь звёздочку.
2. Если нужна ссылка на сообщение, то тебе нужен его уникальный ID, состоящий из 20 символов.
В IDEC Mobile он находится снизу темы сообщения, прямо под отправителем и получателем. Отображается как "msgid: blablabla"
Достаточно просто коротко тапнуть на надпись "msgid", и этот айдишник скопируется в буфер обмена.
В CutieFeed msgid тоже отображается, его можно выделить и скопировать.
3. Для IDEC Mobile есть и третий вариант. Наверху справа в верхней панели есть кнопка с тремя точками, где меню. В меню есть пункт "сохранить в файл".
Сообщение вместе с айдишником сохраняется в текстовый файл. Тоже полезно.
Также в этой менюшке есть пункт "поделиться", который делает похожую вещь. msgid в тексте сообщения тоже сохраняется
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: Как взять на карандаш
idec.talks
Anotheroneuser(syscall,27) — vit01
2018-11-02 05:04:00
Ого. Благодарю тебя.
О CutieFeed мне до сих пор слышать не приходилось, кстати.
idec.talks
Anotheroneuser(syscall,27) — vit01
2018-11-02 05:04:00
Ого. Благодарю тебя.
О CutieFeed мне до сих пор слышать не приходилось, кстати.
[>]
Re: Как взять на карандаш
idec.talks
vit01(mira, 1) — Anotheroneuser
2018-11-02 05:38:34
Anotheroneuser> О CutieFeed мне до сих пор слышать не приходилось, кстати.
https://github.com/idec-net/cutiefeed
Вдруг пригодится
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
idec.talks
vit01(mira, 1) — Anotheroneuser
2018-11-02 05:38:34
Anotheroneuser> О CutieFeed мне до сих пор слышать не приходилось, кстати.
https://github.com/idec-net/cutiefeed
Вдруг пригодится
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: Как взять на карандаш
idec.talks
Anotheroneuser(syscall,27) — vit01
2018-11-03 08:07:57
Пригодится, наверняка. Только разберусь, как его запускать..
idec.talks
Anotheroneuser(syscall,27) — vit01
2018-11-03 08:07:57
Пригодится, наверняка. Только разберусь, как его запускать..
[>]
Re: Как взять на карандаш
idec.talks
btimofeev(tavern,13) — vit01
2018-11-04 07:04:14
vit01> 2. Если нужна ссылка на сообщение, то тебе нужен его уникальный ID, состоящий из 20 символов.
vit01> Достаточно просто коротко тапнуть на надпись "msgid", и этот айдишник скопируется в буфер обмена.
Кстати, а как потом найти по этому id сообщение (в мобильном клиенте)? Если вбиваю в поиск, то не находит. И если сообщения нет в базе, то клиент показывает, что его нет: было бы замечательно, что бы он его предлагал скачать или сразу скачивал.
idec.talks
btimofeev(tavern,13) — vit01
2018-11-04 07:04:14
vit01> 2. Если нужна ссылка на сообщение, то тебе нужен его уникальный ID, состоящий из 20 символов.
vit01> Достаточно просто коротко тапнуть на надпись "msgid", и этот айдишник скопируется в буфер обмена.
Кстати, а как потом найти по этому id сообщение (в мобильном клиенте)? Если вбиваю в поиск, то не находит. И если сообщения нет в базе, то клиент показывает, что его нет: было бы замечательно, что бы он его предлагал скачать или сразу скачивал.
[>]
Re: Как взять на карандаш
idec.talks
vit01(mira, 1) — btimofeev
2018-11-04 07:23:22
vit01>> Достаточно просто коротко тапнуть на надпись "msgid", и этот айдишник скопируется в буфер обмена.
btimofeev> Кстати, а как потом найти по этому id сообщение (в мобильном клиенте)? Если вбиваю в поиск, то не находит. И если сообщения нет в базе, то клиент показывает, что его нет: было бы замечательно, что бы он его предлагал скачать или сразу скачивал.
Достаточно лишь перейти по ii-ссылке вида ii://2GfFXMiDX4GNqmn01BjK из браузера или из любого другого приложения
А если сообщения нет в базе, то Меню -> "Обновить с сервера"
Предлагать скачивать - это неплохая идея, надо будет реализовать
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
idec.talks
vit01(mira, 1) — btimofeev
2018-11-04 07:23:22
vit01>> Достаточно просто коротко тапнуть на надпись "msgid", и этот айдишник скопируется в буфер обмена.
btimofeev> Кстати, а как потом найти по этому id сообщение (в мобильном клиенте)? Если вбиваю в поиск, то не находит. И если сообщения нет в базе, то клиент показывает, что его нет: было бы замечательно, что бы он его предлагал скачать или сразу скачивал.
Достаточно лишь перейти по ii-ссылке вида ii://2GfFXMiDX4GNqmn01BjK из браузера или из любого другого приложения
А если сообщения нет в базе, то Меню -> "Обновить с сервера"
Предлагать скачивать - это неплохая идея, надо будет реализовать
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: Как взять на карандаш
idec.talks
Difrex(tavern,23) — Anotheroneuser
2018-11-04 09:13:45
Anotheroneuser> Нельзя ли мне какую-нибудь схему.. или ссылку на объяснение-для-лиц-далёких-от?
Anotheroneuser> А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.
Не знаю будет ли тебе удобно, но на https://dynamic.lessmore.pw есть избранное.
Щелкаешь на зведочку в правом нижнем углу сообщения и оно добавляется в твое избранное,
потом увидеть можно тут: https://dynamic.lessmore.pw/favorites
// Починил ноду(IDEC API) на динамике. Работают схемы x/c, list.txt, m, e, u/m, u/e
+++ Емакс не пищит и текст не портит
idec.talks
Difrex(tavern,23) — Anotheroneuser
2018-11-04 09:13:45
Anotheroneuser> Нельзя ли мне какую-нибудь схему.. или ссылку на объяснение-для-лиц-далёких-от?
Anotheroneuser> А ещё лучше -- просто подсказку, как запоминать адреса конкретных сообщений.
Не знаю будет ли тебе удобно, но на https://dynamic.lessmore.pw есть избранное.
Щелкаешь на зведочку в правом нижнем углу сообщения и оно добавляется в твое избранное,
потом увидеть можно тут: https://dynamic.lessmore.pw/favorites
// Починил ноду(IDEC API) на динамике. Работают схемы x/c, list.txt, m, e, u/m, u/e
+++ Емакс не пищит и текст не портит
[>]
Re: Как взять на карандаш
idec.talks
btimofeev(tavern,13) — vit01
2018-11-04 09:31:51
vit01> Достаточно лишь перейти по ii-ссылке вида ii://2GfFXMiDX4GNqmn01BjK из браузера или из любого другого приложения
Неплохо, если бы клиент умел искать сообщения по id. А то по тексту умеет, а id игнорирует.
idec.talks
btimofeev(tavern,13) — vit01
2018-11-04 09:31:51
vit01> Достаточно лишь перейти по ii-ссылке вида ii://2GfFXMiDX4GNqmn01BjK из браузера или из любого другого приложения
Неплохо, если бы клиент умел искать сообщения по id. А то по тексту умеет, а id игнорирует.
[>]
Загейтуйте динамик
idec.talks
Difrex(tavern,23) — All
2018-11-04 15:26:24
Сабж. А именно эху ii.test.14. Я начинаю тестирование писанины, как через веб, так и через клиент :)
+++ картошки хватит на всех
idec.talks
Difrex(tavern,23) — All
2018-11-04 15:26:24
Сабж. А именно эху ii.test.14. Я начинаю тестирование писанины, как через веб, так и через клиент :)
+++ картошки хватит на всех
[>]
Re: Загейтуйте динамик
idec.talks
vit01(mira, 1) — Difrex
2018-11-04 16:25:18
Загейтовано.
2All: проверьте в pipe.2032 сообщения ii://2QzNqUiyuoPcPn0l74KP и ii://0dIDXSJTLtR8N2KnLTl1 , они порченные, без текста
idec.talks
vit01(mira, 1) — Difrex
2018-11-04 16:25:18
Загейтовано.
2All: проверьте в pipe.2032 сообщения ii://2QzNqUiyuoPcPn0l74KP и ii://0dIDXSJTLtR8N2KnLTl1 , они порченные, без текста
[>]
Re: Как взять на карандаш
idec.talks
vit01(mira, 1) — Anotheroneuser
2018-11-04 16:32:18
> Пригодится, наверняка. Только разберусь, как его запускать..
На Арче из зависимостей только python, bash и python-pyqt5
На Дебиане/Убунте список зависимостей такой: python3-pyqt5, python3-pyqt5.qtsvg
Запускать сам клиент очень просто: файлик cutiefeed.py
Либо пометить для исполнения, либо набрать python3 cutiefeed.py
idec.talks
vit01(mira, 1) — Anotheroneuser
2018-11-04 16:32:18
> Пригодится, наверняка. Только разберусь, как его запускать..
На Арче из зависимостей только python, bash и python-pyqt5
На Дебиане/Убунте список зависимостей такой: python3-pyqt5, python3-pyqt5.qtsvg
Запускать сам клиент очень просто: файлик cutiefeed.py
Либо пометить для исполнения, либо набрать python3 cutiefeed.py
[>]
Re: Как взять на карандаш
idec.talks
Anotheroneuser(syscall,27) — vit01
2018-11-04 17:25:20
Тээкс.. Сейчас попробую..
idec.talks
Anotheroneuser(syscall,27) — vit01
2018-11-04 17:25:20
Тээкс.. Сейчас попробую..
[>]
Re: Загейтуйте динамик
idec.talks
Anotheroneuser(syscall,27) — Difrex
2018-11-05 06:54:14
> Загейтуйте
Как это по-русски?)) «Закрыть ворота»?
+++ А вы пощупайте-пощупайте! В нашем деле главное — пощупать.
idec.talks
Anotheroneuser(syscall,27) — Difrex
2018-11-05 06:54:14
> Загейтуйте
Как это по-русски?)) «Закрыть ворота»?
+++ А вы пощупайте-пощупайте! В нашем деле главное — пощупать.
[>]
Странности IDEC Mobile
idec.talks
Difrex(tavern,23) — All
2018-11-06 08:44:46
А это норм, что IDEC Mobile в качесте нового сообщения формирует такой вот текст?
Т.е. всего 3 строки в заголовке, хотя в стандарте у нас вот что:
idec.talks
Difrex(tavern,23) — All
2018-11-06 08:44:46
А это норм, что IDEC Mobile в качесте нового сообщения формирует такой вот текст?
ii.test.14 All another test Test
Т.е. всего 3 строки в заголовке, хотя в стандарте у нас вот что:
1 echoarea эхоконференция, в которую помещается сообщение 2 msgto пользователь, которому вы пишете (либо All, если обращаетесь ко всем) 3 subj тема сообщения 4 - пустая строка 5 repto если начинается с @Repto:, то нода проставляет тэг repto (указывает id письма, на которое отвечаем). Иначе строка относится к тексту сообщения 6 и далее msg текст сообщения
[>]
Re: Странности IDEC Mobile
idec.talks
vit01(mira, 1) — Difrex
2018-11-06 11:42:29
Difrex> А это норм, что IDEC Mobile в качесте нового сообщения формирует такой вот текст?
Такого быть не может, иначе сообщение не отправится
Я перепроверил, всё норм создаётся
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
idec.talks
vit01(mira, 1) — Difrex
2018-11-06 11:42:29
Difrex> А это норм, что IDEC Mobile в качесте нового сообщения формирует такой вот текст?
Такого быть не может, иначе сообщение не отправится
Я перепроверил, всё норм создаётся
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
The dynamic.lessmore.pw has clients support
idec.talks
Difrex(dynamic,1) — All
2018-11-06 15:44:00
Собственно сабж. Можно читать и писать. Протестированы все основные клиенты,
исправленны все найденные(мною) баги. Попутно добавились фичи и исправления в пакет go-idec.
Исходники ноды отзеркалены на гитхаб: https://github.com/idec-net/lessmore-node
На этой или следующей неделе появится возможность постить из веб-гуйни.
Выпью пива :)
// А еще на работе зарелизили в прод сегодня систему автоматического инцидент-менеджмента
+++ Caesium/0.4 RC1
idec.talks
Difrex(dynamic,1) — All
2018-11-06 15:44:00
Собственно сабж. Можно читать и писать. Протестированы все основные клиенты,
исправленны все найденные(мною) баги. Попутно добавились фичи и исправления в пакет go-idec.
Исходники ноды отзеркалены на гитхаб: https://github.com/idec-net/lessmore-node
На этой или следующей неделе появится возможность постить из веб-гуйни.
Выпью пива :)
// А еще на работе зарелизили в прод сегодня систему автоматического инцидент-менеджмента
+++ Caesium/0.4 RC1
[>]
Re: Загейтуйте динамик
idec.talks
Difrex(dynamic,1) — Anotheroneuser
2018-11-06 17:16:49
Anotheroneuser> > Загейтуйте
Anotheroneuser> Как это по-русски?)) «Закрыть ворота»?
Зацени, что у нас есть https://ii-net.tk/idec-doc/?p=terminology :)
+++ Емакс не пищит и текст не портит
idec.talks
Difrex(dynamic,1) — Anotheroneuser
2018-11-06 17:16:49
Anotheroneuser> > Загейтуйте
Anotheroneuser> Как это по-русски?)) «Закрыть ворота»?
Зацени, что у нас есть https://ii-net.tk/idec-doc/?p=terminology :)
+++ Емакс не пищит и текст не портит
[>]
Re: Загейтуйте динамик
idec.talks
Anotheroneuser(syscall,27) — Difrex
2018-11-06 17:36:25
Словарище.
Загейтуйте динамик.
Сабж. А именно эху ii.test.14. Я начинаю тестирование писанины, как через веб, так и через клиент
Синхронизируйте узел "динамик".
Такая вот тема сообщения.
Синхронизировать нужно эху ii.test.14.
# Так и не понял, как перевести "эха". Получается, что сеть состоит из узлов, которые, в свою очередь, содержат ленты сообщений. А ленты содержат сообщения. А сообщения могут находиться вне лент? )) Где-нибудь в нигде.
Ну, дальше понятно без перевода.
На самом деле, интересная штука -- это ваше программирование. Но я никак не могу себя заинтересовать им более, чем инструментом для создания игр.. Наверное, не дано.
idec.talks
Anotheroneuser(syscall,27) — Difrex
2018-11-06 17:36:25
Словарище.
Загейтуйте динамик.
Сабж. А именно эху ii.test.14. Я начинаю тестирование писанины, как через веб, так и через клиент
Синхронизируйте узел "динамик".
Такая вот тема сообщения.
Синхронизировать нужно эху ii.test.14.
# Так и не понял, как перевести "эха". Получается, что сеть состоит из узлов, которые, в свою очередь, содержат ленты сообщений. А ленты содержат сообщения. А сообщения могут находиться вне лент? )) Где-нибудь в нигде.
Ну, дальше понятно без перевода.
На самом деле, интересная штука -- это ваше программирование. Но я никак не могу себя заинтересовать им более, чем инструментом для создания игр.. Наверное, не дано.