> Это было в ii.

curl -XGET http://idec.spline-online.ru/x/features
u/e
list.txt
blacklist.txt
x/file
x/small-echolist
x/caesium
x/c

AL> Это было в ii.

AL> Внимание! Вопрос: какая у тебя OS и какое окружение? Пользуешься веб-браузером?

hugeping> P.S. Когда цезий возродишь? :)

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

>> Но вред файлэх в чём?
shaos> 1. Там передаётся нетекстовая информация т.е. через терминал уже не будет работать

shaos> 2. Функционально файл из файлэхи это просто забирание файла по HTTP - зачем городить лишние абстракции?

shaos> 3. Сейчас (на таверне) оно используется в основном только для раздачи порнухи и пиратских книг...

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

AL>> Удивительно. 9 лет у всех всё доходит, а у тебя нет. Может, надо что-то в фетчере поменять?
revoltech> Наверное, мы о разных вещах говорим.
revoltech> 1. Фетчер по server-side слайсу качает 100 последних сообщений вечером.
revoltech> 2. За ночь в эхе появляется 103 сообщения.
revoltech> 3. Фетчер по server-side слайсу качает 100 последних сообщений утром.
revoltech> Вопрос знатокам: увидит ли клиент те несчастные три сообщения?

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

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

shaos>> И кстати зачем родили IDEC если ii был такой уютненький и самодостаточный? ;)
revoltech> Да вот не знаю, кстати, мне пока что только расширение с list.txt полезным показалось.

+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.

hugeping> Я тут подумал и понял, что не могу предложить никакого другого варианта фетчинга. Кроме того, что сделал в ii-go (на основе слайсов). Опишу варианты, которые рассматривал.

hugeping> 1) Вариант с запросом "дай мне все, что позже такого-то хеша" не сработает так как порядок сообщений в базе может быть разным;

Хотя, сработает. Если брать с разумным "запасом" на самом деле... Правда опять вопросы с блеклистами и удалениями могут быть.

> Там ещё идея с подменой (amend) сообщений выглядит интересной - идеологически верная альиернатива редактированию старых мессаг...

> Идея с счётчиками работает ТОЛЬКО в условиях ii. Когда все базы одинаковы.

> Конечно, сейчас хочется сказать - а давайте вернёмся и придумаем что-то более простое и надёжное и сделаем что-то среднее между ii и idec... Но боюсь, лишние потрясения нам не к чему.

doesnm> Работает - не трогай?

shaos>> хотя не - max(index) не будет работать т.к. индекс общий на все эхи
shaos>> видимо надо запрещать удалять сообщения физически...
hugeping> Идея с счётчиками работает ТОЛЬКО в условиях ii. Когда все базы одинаковы. Тогда ничего не надо городить и счётчик - полное число сообщений эхи, включая блеклист. Вот меня тоже давно грызёт мысль что нужно что-то упрощать. Но я боюсь что то менять. :)

+++ Никто не знает, как правильно. Так зачем же выдумывать правила?

shaos> хотя не - max(index) не будет работать т.к. индекс общий на все эхи
shaos> видимо надо запрещать удалять сообщения физически...

shaos>> в ii-php уменьшается

revoltech> Ну, это печально. Получается, спецификации оно не соблюдает. Соответственно, в клиентах вся завязанная на счётчики логика тоже идёт лесом.

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

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

Конечно, сейчас хочется сказать - а давайте вернёмся и придумаем что-то более простое и надёжное и сделаем что-то среднее между ii и idec... Но боюсь, лишние потрясения нам не к чему.

shaos> в ii-php уменьшается

shaos> Сообщение можно не только заблеклистить, но и удалить

> Важно: параметр неубывающий. Если в эхе удалили сообщения, то возвращаемое число не должно уменьшаться.

> Но вред файлэх в чём?

hugeping> Потому что в разных нодах могут быть особенности. Например блеклист - учитывается или нет в счётчиках? Нода может не хранить все сообщения, а только часть (последние 10000).

> На этот счёт спецификация явно говорит, что счётчик может только увеличиваться.