Skip to content

Instantly share code, notes, and snippets.

@liuch liuch/psi_new_history.md
Last active Jul 21, 2017

Embed
What would you like to do?
Обсуждение функциональности хранения и отображения истории для Psi+

Обсуждение функциональности хранения и отображения истории для Psi+

Функциональность затрагивающая хранилище (касается только SQL версии хранилища).

  • Хранение истории переписки в привате конференций. Реализовано. По умолчанию отключено, включать тут: options.history.store-muc-private
  • Хранение логов самой конференции, опционально. А надо ли?
  • Раздельное хранение истории по аккаунтам. Добавить таблицу accounts. Реализовано.
  • Значение, указывающее длительность хранения истории в разрезе по аккаунтам и отдельным контактам. В том числе нежелание хранить историю. Поле типа int в таблицах accounts и contacts. Соответствующие поля уже имеются в структуре БД, пока не используются.
  • Служебная таблица с полями ключ и значение что бы хранить специфичную для хранилища информацию и настройки. Например версию структуры БД. Реализовано, см. таблицу SYSTEM.
  • Хранить ресурс с которого пришло сообщение. Реализовано.

Функциональность затрагивающая GUI и возможно затрагивающая API запросов к хранилищу.

  • Избавится от кнопок в нижней части диалога просмотра истории (Earliest, Previous и т.д.). Переделать на динамическую подгрузку истории по требованию.
  • Загрузка последних нескольких сообщений из истории в окно чата и окно привата конференции. Пока реализовано только для невебкит версии. По умолчанию подгружаются 5 последних сообщений. Меняется тут: options.ui.chat.history.preload-history-size
  • Просмотр истории не только по выбранному контакту но и по всем контактам и/или всем аккаунтам. В том числе поиск. Несложно реализовать только для sql версии. Реализовано.
  • Учесть возможность получения и просмотра истории из внешнего хранилища, например XEP-0136.

Разное

  • Вынести все сохранение истории в отдельные модули, с возможностью получения списка реализованной функциональности.
  • Реализовать работу с любым типом хранилища отдельным потоком.
  • Желательно утрясти API доступа к хранилищу истории, выделить оптимизации касающиеся хранения истории в файлах и вынести отдельным патчем. Сейчас в патче есть изменения «файловой» истории касающиеся не только API.
  • Учесть возможность записи истории в несколько разных хранилищ. Например в файлы со старым форматом и в новый формат. Сейчас именно так пишется, но цель и реализация другие.

Структура БД

Таблица system

Таблица предназначена для хранения специфичной для хранилища информации и настроек. Обращение к этой таблице будет минимизировано. Изначально, при создании хранилища, в этой таблице будет одна запись - версия структуры БД.

CREATE TABLE `system` (
  `key` TEXT,
  `value` TEXT
  );
INSERT INTO `system` (`key`, `value`) VALUES ("version", "1");
  • key (строка) - ключ, имя параметра.
  • value (строка) - значение параметра.

Таблица accounts

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

CREATE TABLE `accounts` (
  `id` TEXT,
  `lifetime` INTEGER
  );
  • id (целое) - уникальный идентификатор аккаунта, то же что и в accounts.xml. Позволяет идентифицировать запись для различных операций.
  • lifetime (целое) - максимальное количество дней для хранения истории. -1 Хранить бесконечно, 0 - не хранить, lifetame > 0 - хранить указанное количество дней.

Таблица contacts

Фактически, список контактов для которых есть сохраненные события.

CREATE TABLE `contacts` (
  `id` INTEGER NOT NULL PRIMARY KEY ASC,
  `acc_id` TEXT,
  `type` INTEGER,
  `jid` TEXT,
  `lifetime` INTEGER
  );
  • id (целое) - уникальный идентификатор записи. Позволяет идентифицировать запись для различных операций. Так же необходима для связи с таблицей events.
  • acc_id (строка) - id аккаунта.
  • type (целое) - Тип контакта. Contact = 1, GroupChatContact = 2.
  • jid (строка) - JID контакта без ресурса. Для записи привата конференции записывается с ресурсом (ником).
  • lifetime (целое) - максимальное количество дней для хранения истории. Имеет приоритет над значением, указанным в accounts.

Таблица events

Основная таблица для хранения тела события. Это могут быть сообщения, чат, запросы авторизации, их подтверждение и т.п.

CREATE TABLE `events` (
  `id` INTEGER NOT NULL PRIMARY KEY ASC AUTOINCREMENT,
  `contact_id` INTEGER NOT NULL REFERENCES `contacts`(`id`) ON DELETE CASCADE,
  `resource` TEXT,
  `date` TEXT,
  `type` INTEGER,
  `direction` INTEGER,
  `subject` TEXT,
  `m_text` TEXT,
  `lang` TEXT,
  `extra_data` TEXT
  );
  • id (целое) - уникальный идентификатор записи. Позволяет идентифицировать запись для различных операций. Так же необходима для связи с таблицей urls.
  • contact_id (целое) - для связи с таблицей contacts.
  • resource (строка) - ресурс контакта, с которого или на который отправлено сохраняемое событие.
  • date (строка) - дата и время события. Строковое значение используется из-за ограничений в SQLite.
  • type (целое) - тип сохраненного события (chat, error, headline, subscribe и т.п.). Да, отображается не все из того что сохраняется. Значение и наличие этого поля обусловлено реализацией в "старой" версии хранения истории.
  • direction (целое) - нам событие или от нас. Наше - 1, Нам - 2.
  • subject (текст) - subject сообщения
  • m_text (текст) - текст сообщения
  • lang (текст) - lang сообщения
  • extra_data (текст) - дополнительные данные, связанные с событием в формате json. Например в этом поле хранятся урлы, прекрепленные к сообщению (XEP-0066).

В SQLite версии хранилища сохраняется столько же данных сколько в хранилище на файлах. Кроме хранения приватов конференций и списка ссылок в сообщении (в старой реализации сохраняется только первая ссылка, остальные отбрасываются).

@Ri0n

This comment has been minimized.

Copy link

commented Jun 26, 2013

direction (целое) - нам событие или от нас. Наше - 1, Нам - 2.

настоящие программисты считают с нуля =))

@liuch

This comment has been minimized.

Copy link
Owner Author

commented Jul 23, 2013

настоящие программисты считают с нуля =))

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

зы. Как тут подписаться на уведомления о новых комментариях?

@wadealer

This comment has been minimized.

Copy link

commented Feb 16, 2014

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

@corpix

This comment has been minimized.

Copy link

commented Mar 4, 2014

@wadealer плюсую, удобно.

@liuch

This comment has been minimized.

Copy link
Owner Author

commented Mar 18, 2014

Так это уже реализовано. Достаточно вместо конкретного аккаунта выбрать All Accounts. Т.е. эмулировать ничего не надо. Или имелась ввиду опция, которая позволяет выбирать соотв. пункт по умолчанию?

@wadealer

This comment has been minimized.

Copy link

commented May 14, 2014

AllAccounts - это не то. В данном случае я все равно вижу 2 (или больше) контактов одного и того же человека (с одинаковыми джидами, но разными аккаунтами в квадратных скобках). Хочу видеть один контакт с общей историей.

Еще. Старые сообщения в окне чата очень плохо отделяются от новых. Нужно хотя-бы линию рисовать. Или как-то еще более явно выделять. ТОлько цветом недостаточно, особенно это касается жуйки и других ботов.

@wadealer

This comment has been minimized.

Copy link

commented May 15, 2014

Еще у меня таблица accounts пустая
http://pix.academ.org/img/2014/05/15/cfc919d312792f424e5019be83990e55.png
Почему?

@liuch

This comment has been minimized.

Copy link
Owner Author

commented May 20, 2014

Еще у меня таблица accounts пустая

Так и должно быть. Для получения истории достаточно данных, находящихся в других таблицах. Эта таблица нужна только ради lifetime. Т.е. для реализации автоматического стирания сообщений при их устаревании.

AllAccounts - это не то. В данном случае я все равно вижу 2 (или больше) контактов одного и того же человека (с одинаковыми джидами, но разными аккаунтами в квадратных скобках). Хочу видеть один контакт с общей историей.

Теперь понятно. Сделаем.

Еще. Старые сообщения в окне чата очень плохо отделяются от новых. Нужно хотя-бы линию рисовать. Или как-то еще более явно выделять. ТОлько цветом недостаточно, особенно это касается жуйки и других ботов.

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

@de1eted

This comment has been minimized.

Copy link

commented Aug 6, 2014

А возможно ли подтянуть историю с сервера (xep-0136)?

@liuch

This comment has been minimized.

Copy link
Owner Author

commented Aug 27, 2014

А возможно ли подтянуть историю с сервера (xep-0136)?

В текущей реализации - нет.

@ssten

This comment has been minimized.

Copy link

commented Dec 30, 2014

Журналирование конференции — нужно.
Локальной опцией (с возможностью задания значений для всех используемых чятиков).
Умолчательное значение берётся из глобального представления опции.

Оно конечно очевидно.
Но явно не сказано, а по мне надо бы:
Импорт архива истории из старого формата (файлы).
Возможно вместе с экспортом.

ЗЫ: И хорошо бы приложить ссылку на код.

@wadealer

This comment has been minimized.

Copy link

commented Mar 4, 2016

В каком сейчас состоянии данный патч? Может уже пора переливать в main?

@beelze

This comment has been minimized.

Copy link

commented Jun 27, 2017

Пожелания и мысли по поводу интерфейса истории:

  1. календарь и кнопки earliest, prev, next, latest не особо необходимы, как и нынешний способ отображения истории (в основном по причине того, что при поиске нельзя увидеть более одного результата
  2. хотелось бы иметь просмотр истории в виде, приближенном к браузеру записей с фильтром (контакт, период, текст, сортировка). Здесь на мой взгляд, важны 2 момента:
    а) поиск в поле м_текст должен тем или иным образом реализовывать fuzzy логику (лучше всего регексом). Это нужно потому, что чаще всего помнится приблизительный текст (например я хочу найти, где я обсуждал определенную прошивку – помню что копипастил нечто c консоли, но приблизительно, регексом могу это написать, а точной подстрокой – нет.)
    б) в браузере записей хотелось бы видеть не только найденную запись, но и «контекст» (окружающие записи). Здесь уместны критерии типа «показывать n предыдущих и последующих записей» и/или «показывать записи, отличающиеся по времени не более чем на n секунд».
@liuch

This comment has been minimized.

Copy link
Owner Author

commented Jul 21, 2017

@beelze Поиск по истории и позиционирование по календарю уже переделаны. В том числе отображается контекст в результатах поиска в режиме "n записей до и после". На счет регулярок - тут надо думать. Это сильно замедлит поиск.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.