# Re: Протокол IDEC
Andrew Lobanov (tavern,1) → mirage – 05:43:49 2018-10-10
mirage> Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.
Как ты это видишь в текущем варианте? Как из ID получить что-то типа -10:10?
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → mirage – 05:43:49 2018-10-10
mirage> Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.
Как ты это видишь в текущем варианте? Как из ID получить что-то типа -10:10?
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
# Re: Протокол IDEC
Andrew Lobanov (tavern,1) → mirage – 05:43:49 2018-10-10
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
>> Читать далее
Andrew Lobanov (tavern,1) → mirage – 05:43:49 2018-10-10
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
Peter (syscall,1) → mirage – 05:15:37 2018-10-10
> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
Peter (syscall,1) → mirage – 05:15:37 2018-10-10
> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
Согласен. У Ромы в его gk11 (было такое развитие ii с его стороны) был запрос по времени. Типа, дай всё что было после такого-то времени. И это лучше, конечно. Но так уж получилось.
# Re: Протокол IDEC
mirage (syscall,44) → mirage – 04:48:04 2018-10-10
AL>>>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage>>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>>> Только возникнет проблема если это сообщение будет удалено.
AL>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage> Несколько десятков ID и получит. Только новое.
mirage> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage> И получает ID4 ID5 ID6 и запоминает ID6.
mirage> Весь индекс тянуть заново не надо.
Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.
>> Читать далее
mirage (syscall,44) → mirage – 04:48:04 2018-10-10
AL>>>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage>>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>>> Только возникнет проблема если это сообщение будет удалено.
AL>> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
mirage> Несколько десятков ID и получит. Только новое.
mirage> Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
mirage> Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
mirage> На ноду еще приходят сообщения: ID4 ID5 ID6.
mirage> В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
mirage> И получает ID4 ID5 ID6 и запоминает ID6.
mirage> Весь индекс тянуть заново не надо.
Ну и можно тоже тянуть слайсами. Просить N ids от последнего id. Последний запомнить и опять N от последнего.
>> Читать далее
# Re: Протокол IDEC
mirage (syscall,44) → Andrew Lobanov – 03:36:32 2018-10-10
AL>>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
AL> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
Несколько десятков ID и получит. Только новое.
Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
На ноду еще приходят сообщения: ID4 ID5 ID6.
В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
И получает ID4 ID5 ID6 и запоминает ID6.
Весь индекс тянуть заново не надо.
>> Читать далее
mirage (syscall,44) → Andrew Lobanov – 03:36:32 2018-10-10
AL>>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage>> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage>> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage>> Только возникнет проблема если это сообщение будет удалено.
AL> А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
Несколько десятков ID и получит. Только новое.
Вот есть на ноде в эхе сообщения: ID1 ID2 ID3.
Фетчер качает их и запоминает что последнее скачаное для этой ноды-эхи - ID3.
На ноду еще приходят сообщения: ID4 ID5 ID6.
В следующий раз фетчер спрашивает у ноды: дай все что после ID3.
И получает ID4 ID5 ID6 и запоминает ID6.
Весь индекс тянуть заново не надо.
>> Читать далее
# Re: Протокол IDEC
Andrew Lobanov (tavern,1) → mirage – 02:43:30 2018-10-10
AL>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage> Только возникнет проблема если это сообщение будет удалено.
А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → mirage – 02:43:30 2018-10-10
AL>> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
mirage> Эха содержит список id сообщений. Если новые id добавляются только в конец,
mirage> то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
mirage> Только возникнет проблема если это сообщение будет удалено.
А если между запросами пришло не одно сообщение, а несколько десятков? Снова тянуть весь индекс, который может весить мегабайты? Так я точно знаю насколько изменилась длина индекса с прошлой сессии и могу скачать соответствующий слайс индекса.
+++ IDEC-Mobile
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
# Re: Caesium и файлэхи
mirage (syscall,44) → Peter – 20:59:37 2018-10-09
Peter> Фехи не поддерживаются этой нодой (syscall) :)
Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
+++ Caesium/0.4 RC1
mirage (syscall,44) → Peter – 20:59:37 2018-10-09
Peter> Фехи не поддерживаются этой нодой (syscall) :)
Я знаю, поэтому пытаюсь качать с http://idec.spline-online.tk/
+++ Caesium/0.4 RC1
# Re: Caesium и файлэхи
Peter (syscall,1) → mirage – 20:55:45 2018-10-09
Фехи не поддерживаются этой нодой (syscall) :)
Peter (syscall,1) → mirage – 20:55:45 2018-10-09
Фехи не поддерживаются этой нодой (syscall) :)
# Re: Протокол IDEC
mirage (syscall,44) → Andrew Lobanov – 20:17:53 2018-10-09
mirage>>>> | GET /x/с/<параметры>
mirage>>>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>>>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
AL> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
Эха содержит список id сообщений. Если новые id добавляются только в конец,
то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
Только возникнет проблема если это сообщение будет удалено.
Другой вариант при запросе методом инкрементного листинга нода может записывать в файл эхи метку вида ">node_name"
и при следующем запросе отдавать список от этой метки и двигать ее в конец.
Я больше склоняюсь к первому варианту, он более гибкий, простой и стабильный.
>> Читать далее
mirage (syscall,44) → Andrew Lobanov – 20:17:53 2018-10-09
mirage>>>> | GET /x/с/<параметры>
mirage>>>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>>>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01>>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage>> Тогда это уже не количество сообщений будет, а что-то другое.
AL> На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
Эха содержит список id сообщений. Если новые id добавляются только в конец,
то фетчер может хранить id последнего полученного сообщения и запрашивать от него.
Только возникнет проблема если это сообщение будет удалено.
Другой вариант при запросе методом инкрементного листинга нода может записывать в файл эхи метку вида ">node_name"
и при следующем запросе отдавать список от этой метки и двигать ее в конец.
Я больше склоняюсь к первому варианту, он более гибкий, простой и стабильный.
>> Читать далее
# Re: Caesium и файлэхи
mirage (syscall,44) → Andrew Lobanov – 19:36:39 2018-10-09
mirage>> В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.
AL> Это баг в цезии, который я всё никак не поправлю. Просто времени сейчас нет особо. Попробуй вбить произвольную строку авторизации в конфиг и получить файлы.
Пробовал. Не фетчит.
+++ Caesium/0.4 RC1
mirage (syscall,44) → Andrew Lobanov – 19:36:39 2018-10-09
mirage>> В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.
AL> Это баг в цезии, который я всё никак не поправлю. Просто времени сейчас нет особо. Попробуй вбить произвольную строку авторизации в конфиг и получить файлы.
Пробовал. Не фетчит.
+++ Caesium/0.4 RC1
# Re: Caesium и файлэхи
Andrew Lobanov (tavern,1) → mirage – 17:32:17 2018-10-09
mirage> Сабж как? В документации нет.
Добавь в конфиг что-то типа
и всё.
mirage> В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.
Это баг в цезии, который я всё никак не поправлю. Просто времени сейчас нет особо. Попробуй вбить произвольную строку авторизации в конфиг и получить файлы.
+++ Caesium/0.4 RC1
Andrew Lobanov (tavern,1) → mirage – 17:32:17 2018-10-09
mirage> Сабж как? В документации нет.
Добавь в конфиг что-то типа
fecho pictures
и всё.
mirage> В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.
Это баг в цезии, который я всё никак не поправлю. Просто времени сейчас нет особо. Попробуй вбить произвольную строку авторизации в конфиг и получить файлы.
+++ Caesium/0.4 RC1
# Re: Протокол IDEC
Andrew Lobanov (tavern,1) → mirage – 17:32:17 2018-10-09
mirage>>> | GET /x/с/<параметры>
mirage>>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage> Тогда это уже не количество сообщений будет, а что-то другое.
На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
vit01>> С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
vit01>> Скорее всего, Рома просто забыл про такой вариант, а после него об этом никто не задумывался.
Я задумывался, но реальной пользы не заметил.
mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
>> Читать далее
Andrew Lobanov (tavern,1) → mirage – 17:32:17 2018-10-09
mirage>>> | GET /x/с/<параметры>
mirage>>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01>> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
mirage> Тогда это уже не количество сообщений будет, а что-то другое.
На основе этого x/c мои фетчеры (caesium и iing) определяют оптимальную длину запросов к узлу для экономии трафика. Если ты приведёшь пример как эту информацию получать из хешей, то можно будет подумать.
vit01>> С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
vit01>> Скорее всего, Рома просто забыл про такой вариант, а после него об этом никто не задумывался.
Я задумывался, но реальной пользы не заметил.
mirage> Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
>> Читать далее
# Re: Вопросы/предложения по Caesium
Andrew Lobanov (tavern,1) → mirage – 17:32:16 2018-10-09
mirage> | Esc - выход из режима чтения в режим выбора эхоконференции
mirage> Зачем выбран Esc для этой функции? Он в ncurses тормозит.
mirage> | F10 - выход из клиента
mirage> Лучше не использовать функциональные клавиши. F10 например у меня - меню терминала.
Ты всегда можешь поправить биндинги в keys.py.
+++ Caesium/0.4 RC1
Andrew Lobanov (tavern,1) → mirage – 17:32:16 2018-10-09
mirage> | Esc - выход из режима чтения в режим выбора эхоконференции
mirage> Зачем выбран Esc для этой функции? Он в ncurses тормозит.
mirage> | F10 - выход из клиента
mirage> Лучше не использовать функциональные клавиши. F10 например у меня - меню терминала.
Ты всегда можешь поправить биндинги в keys.py.
+++ Caesium/0.4 RC1
# Caesium и файлэхи
mirage (syscall,44) → All – 16:54:13 2018-10-09
Сабж как? В документации нет.
В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.
+++ Caesium/0.4 RC1
mirage (syscall,44) → All – 16:54:13 2018-10-09
Сабж как? В документации нет.
В коде нашел fecho, но без авторизации похоже не работает. Хотя вручную API без авторизации все отдает.
+++ Caesium/0.4 RC1
# Re: Протокол IDEC
mirage (syscall,44) → vit01 – 16:54:11 2018-10-09
mirage>> | GET /x/с/<параметры>
mirage>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
Тогда это уже не количество сообщений будет, а что-то другое.
vit01> // удалять сообщения может только держатель ноды, и это в будущем так и останется
mirage>> | /u/m/msgid/msgid/msgid
mirage>> Количество msgid лимитировано длиной GET запроса на сервере.
mirage>> Почему вместо этого не передавать msgid в POST?
vit01> С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
vit01> Скорее всего, Рома просто забыл про такой вариант, а после него об этом никто не задумывался.
Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
>> Читать далее
mirage (syscall,44) → vit01 – 16:54:11 2018-10-09
mirage>> | GET /x/с/<параметры>
mirage>> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage>> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
vit01> Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
Тогда это уже не количество сообщений будет, а что-то другое.
vit01> // удалять сообщения может только держатель ноды, и это в будущем так и останется
mirage>> | /u/m/msgid/msgid/msgid
mirage>> Количество msgid лимитировано длиной GET запроса на сервере.
mirage>> Почему вместо этого не передавать msgid в POST?
vit01> С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
vit01> Скорее всего, Рома просто забыл про такой вариант, а после него об этом никто не задумывался.
Ну я сейчас запустил iitxt и он неслолько минут запросы слал по несколько сообщений, а мог бы и быстрее отработать.
>> Читать далее
# Re: Протокол IDEC
vit01 (mira, 1) → mirage – 16:33:30 2018-10-09
mirage> | GET /x/с/<параметры>
mirage> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
// удалять сообщения может только держатель ноды, и это в будущем так и останется
mirage> | /u/m/msgid/msgid/msgid
mirage> Количество msgid лимитировано длиной GET запроса на сервере.
mirage> Почему вместо этого не передавать msgid в POST?
С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
>> Читать далее
vit01 (mira, 1) → mirage – 16:33:30 2018-10-09
mirage> | GET /x/с/<параметры>
mirage> | Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
mirage> Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
Всё просто, поле по-хорошему increment only. А ещё клиентская часть обычно подстраховывается и скачивает индекс с запасом.
// удалять сообщения может только держатель ноды, и это в будущем так и останется
mirage> | /u/m/msgid/msgid/msgid
mirage> Количество msgid лимитировано длиной GET запроса на сервере.
mirage> Почему вместо этого не передавать msgid в POST?
С точки зрения масштабируемости протокола это хорошая идея, но на практике ещё никому не пригождалось скачивать сообщения очень большими порциями.
>> Читать далее
# Re: Протокол IDEC
Peter (syscall,1) → mirage – 16:05:40 2018-10-09
mirage> Количество msgid лимитировано длиной GET запроса на сервере.
mirage> Почему вместо этого не передавать msgid в POST?
Думаю, из соображений простоты. А фетчеры обычно забирают сообщения пачками, скажем, по 16 сообщений. В цикле. Поэтому ограничение не критично.
Peter (syscall,1) → mirage – 16:05:40 2018-10-09
mirage> Количество msgid лимитировано длиной GET запроса на сервере.
mirage> Почему вместо этого не передавать msgid в POST?
Думаю, из соображений простоты. А фетчеры обычно забирают сообщения пачками, скажем, по 16 сообщений. В цикле. Поэтому ограничение не критично.
# Протокол IDEC
mirage (syscall,44) → All – 15:54:33 2018-10-09
Читаю про сабж и не понимаю.
| GET /x/с/<параметры>
| Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
| /u/m/msgid/msgid/msgid
Количество msgid лимитировано длиной GET запроса на сервере.
Почему вместо этого не передавать msgid в POST?
+++ Caesium/0.4 RC1
mirage (syscall,44) → All – 15:54:33 2018-10-09
Читаю про сабж и не понимаю.
| GET /x/с/<параметры>
| Предназначен для отслеживания изменений в эхе и для отсеивания лишнего трафика. Обычное целое число.
Если из эхи можно удалять сообщения, а как я понимаю это планируется, то изменения этим методом обнаружить можно не всегда.
| /u/m/msgid/msgid/msgid
Количество msgid лимитировано длиной GET запроса на сервере.
Почему вместо этого не передавать msgid в POST?
+++ Caesium/0.4 RC1
# Вопросы/предложения по Caesium
mirage (syscall,44) → All – 15:54:31 2018-10-09
| Esc - выход из режима чтения в режим выбора эхоконференции
Зачем выбран Esc для этой функции? Он в ncurses тормозит.
| F10 - выход из клиента
Лучше не использовать функциональные клавиши. F10 например у меня - меню терминала.
+++ Caesium/0.4 RC1
mirage (syscall,44) → All – 15:54:31 2018-10-09
| Esc - выход из режима чтения в режим выбора эхоконференции
Зачем выбран Esc для этой функции? Он в ncurses тормозит.
| F10 - выход из клиента
Лучше не использовать функциональные клавиши. F10 например у меня - меню терминала.
+++ Caesium/0.4 RC1
# Re: Что такое ii?
vit01 (mira, 1) → mirage – 05:22:29 2018-10-09
mirage> Что за клуб и что за ii?
mirage> Попытки найти источник не были успешными.
Всё началось отсюда
https://www.linux.org.ru/news/opensource/10319264
И продолжилось здесь
https://www.linux.org.ru/news/opensource/10534550
Сейчас ii как таковой уже не существует, да и Рома (автор идеи) от нас ушёл, потому что во всём разочаровался и потерял интерес к проекту.
IDEC - это прямой потомок как самой идеи ii, так и его протокола.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
vit01 (mira, 1) → mirage – 05:22:29 2018-10-09
mirage> Что за клуб и что за ii?
mirage> Попытки найти источник не были успешными.
Всё началось отсюда
https://www.linux.org.ru/news/opensource/10319264
И продолжилось здесь
https://www.linux.org.ru/news/opensource/10534550
Сейчас ii как таковой уже не существует, да и Рома (автор идеи) от нас ушёл, потому что во всём разочаровался и потерял интерес к проекту.
IDEC - это прямой потомок как самой идеи ii, так и его протокола.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
# Re: Что такое ii?
Andrew Lobanov (tavern,1) → mirage – 16:16:24 2018-10-08
mirage> Что за клуб и что за ii?
Не осталось уже ни клуба хороших людей (основатель создавал какой-то там кружок любителей OpenBSD, но и тот кончился, вроде) ни, можно сказать, ii.
ii это такой обрезанный idec. Без экономии трафика и файлообмена.
mirage> Попытки найти источник не были успешными.
У меня где-то, возможно, осталась эталонная реализация ii, но не уверен. Посмотрю завтра, если не забуду.
+++ Caesium/0.4 RC1
Andrew Lobanov (tavern,1) → mirage – 16:16:24 2018-10-08
mirage> Что за клуб и что за ii?
Не осталось уже ни клуба хороших людей (основатель создавал какой-то там кружок любителей OpenBSD, но и тот кончился, вроде) ни, можно сказать, ii.
ii это такой обрезанный idec. Без экономии трафика и файлообмена.
mirage> Попытки найти источник не были успешными.
У меня где-то, возможно, осталась эталонная реализация ii, но не уверен. Посмотрю завтра, если не забуду.
+++ Caesium/0.4 RC1
# Что такое ii?
mirage (syscall,44) → All – 15:52:08 2018-10-08
Hi All!
Из документации:
"Берёт своё начало от "Клуба хороших людей" (2014) и работает на распределённом протоколе IDEC
(ii-like Data Exchange Convention), форкнутом от ii (всё от того же "Клуба")."
Что за клуб и что за ii?
Попытки найти источник не были успешными.
+++ Caesium/0.4 RC1
mirage (syscall,44) → All – 15:52:08 2018-10-08
Hi All!
Из документации:
"Берёт своё начало от "Клуба хороших людей" (2014) и работает на распределённом протоколе IDEC
(ii-like Data Exchange Convention), форкнутом от ii (всё от того же "Клуба")."
Что за клуб и что за ii?
Попытки найти источник не были успешными.
+++ Caesium/0.4 RC1
# Re: Ничего не загружается в фаловых эхах
Anotheroneuser (syscall,27) → Peter – 15:07:11 2018-09-29
AL>> Ну либо так либо просить Петра пробросить фэхи =)
Peter> Непроброс фэх
Да я просто хотел картинки посмотреть!))
Добавлю станцию и всё.
Самый верный путь — это когда никого не напрягать.
+++ А вы пощупайте-пощупайте! В нашем деле главное — пощупать.
Anotheroneuser (syscall,27) → Peter – 15:07:11 2018-09-29
AL>> Ну либо так либо просить Петра пробросить фэхи =)
Peter> Непроброс фэх
Да я просто хотел картинки посмотреть!))
Добавлю станцию и всё.
Самый верный путь — это когда никого не напрягать.
+++ А вы пощупайте-пощупайте! В нашем деле главное — пощупать.
# Re: Ничего не загружается в фаловых эхах
Peter (syscall,1) → Andrew Lobanov – 14:43:05 2018-09-29
AL> Ну либо так либо просить Петра пробросить фэхи =)
Непроброс фэх клуба не сколько техническая, сколько принципиальная проблема. Я не могу и не хочу делать из сервера файловое хранилище. Во первых у меня хостинг ограниченный, во вторых -- не хочу его компрометации. :)
Peter (syscall,1) → Andrew Lobanov – 14:43:05 2018-09-29
AL> Ну либо так либо просить Петра пробросить фэхи =)
Непроброс фэх клуба не сколько техническая, сколько принципиальная проблема. Я не могу и не хочу делать из сервера файловое хранилище. Во первых у меня хостинг ограниченный, во вторых -- не хочу его компрометации. :)
# Re: Ничего не загружается в фаловых эхах
Andrew Lobanov (tavern,1) → Anotheroneuser – 13:45:35 2018-09-29
AL>> Насколько я помню, в клубе нет файлэх. Но лучше это уточнить у Петра.
Anotheroneuser> То есть, надо подключиться к другой станции?
Ну либо так либо просить Петра пробросить фэхи =)
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
Andrew Lobanov (tavern,1) → Anotheroneuser – 13:45:35 2018-09-29
AL>> Насколько я помню, в клубе нет файлэх. Но лучше это уточнить у Петра.
Anotheroneuser> То есть, надо подключиться к другой станции?
Ну либо так либо просить Петра пробросить фэхи =)
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.