Сервер профилей

[x2088]

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

[x2088]

Картинко со старого форума. s2p = транспорты.

[x2088]

Возможно, всё ниже сказанное - очевидно, но озвучу на всякий случай.

Если на компе с установленный клиентом (ПИ - пользовательским интерфейсом) нет никакого сервера профилей, то ПИ подключается сразу к глобальному серверу профилей, получая с него все настройки, КЛ, историю и принятые файлы по требованию пользователя или ПИ. Сам ПИ вообще ничерта никак не хранит - всем этим занимается сервер профилей - он неотъемлемая часть клиента, но реализованная отдельно и работающая по сетевому протоколу, взаимодействуя с главным сервером и ПИ как промежуточное звено. Не каждый пакет нужно слать на сервер профилей - обязательно это только для сообщений, файлы в принципе уже вариативны в этом, а сервисные сообщения я вообще не знаю зачем хранить для обычного пользователя - это интересно максимум только админу, простой пользователь глядя на это может разве что посмотреть стабильность соединения и увидеть что всё плохо когда соединению уже совсем труба - не более. Начерта в КЛ делать кнопку для открытия окна истории сервисных сообщений вместо открытия окна, где можно почитать историю с выбором контакта/плагина/асб/сервисных - я не знаю, тем более есть такой же пункт в меню.

Здесь возникает маленькое неудобство - отсутствие последних сообщений в ОС при отсутствии локального сервера профилей, для чего в настройках можно сделать галку для включения костыля в виде локальной БД SQLite3 с последними сообщениями. Я не считаю, что запрашивать последние сообщения с глобального сервера профилей где-то в др сети или интернетах постоянно при каждом запуске - хорошая идея. Даже запрос последней истории с соседнего компа может быть уже так себе. Как вариант можно хранить последние сообщения для избранных контактов, а не для всех. Можно не делать галку, а запускать SQLite молча, но если пользователю оно не надо - какой в этом смысл? Некоторые работают по принципу: новое сообщение -> обработал -> выкинул и забыл, поэтому последние сообщения им не нужны, даже кнопку очистки ОС жмут после обработки сообщения.

Синхронизация между серверами профилей по дефолту производится только для настроек клиента, синхронизация истории должна настраиваться админом и/или пользователем - установка одной галки. В случае с историей должен быть выбор где её хранить на локальном и/или глобальном сервере профилей. С файлами сложнее - они толстые для этого, тут могут быть варианты по числу открытий, размеру, давности файла, давности правки, важности для пользователя. Локальный сервер профилей может быть недоступен из инета, особенно если он установлен дома. Для решения проблемы понадобится присваивать серверам профилей такой же рандомный адрес / ID как 8 байтное число/строка, смена ID тоже должна быть генерацией или прямым вводом. Пользователь / ПИ может отправлять запросы своему локальному серверу профилей с использованием глобального сервера профилей в режиме прокси. В принципе ничто не мешает слать сообщения, минуя сервер профилей, если у вас паранойя - это не значит, что за вами не следят.

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

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

[x2088]

Да, опять забыл. Если кого-то напрягает открытие лишних портов/соединений для локального сервера профилей на том же компе, где установлен клиент / ПИ для взаимодействия с ним - можно использовать обычное подключение DLL без всяких дополнительных открытий портов/соединений. Один фиг тут требуется открыть порт и установить соединение с главным сервером - исходный код в любом случае один и тот же, и новых дыр в безопасности это не добавляет - разница может быть только в необходимости лишнего разбана самого себя в локальном файрволле.

В выпадающем меню кнопки истории КЛ можно сделать выбор что показывать: историю с глобального, локального профиля или SQLite.

[x2088]

Хотя, в принципе сохранение и удаление истории в контекстное меню контакта можно запихнуть, а строку поиска с оставшимися двумя кнопками собрать в одной строке.

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

Доставка до главного сервера и до самого клиента / ПИ никакой роли не играет - важно знать, только что сообщение записано в историю получателя и то, что он его прочитал. Возможна потеря сервисных пакетов о доставке и прочтении - обычно на это кладут болт. Вот чтобы такого не было - точно так же ставить эти сообщения в очередь на повторную отправку пока они не будут доставлены. Пока не получено сообщение о доставке - статус сообщения должен быть "отправляется" и попытки отправки должны повторяться. Точно так же отправлять сообщение в ПИ пока его не прочитают и статус об этом не будет получен сервером профилей, после чего сервер профилей уведомит отправителя о прочтении. Если уведомление прочтения не будет получено, то можно собирать запросы по всем таким сообщениям в кучу и отправлять запрос ещё раз. Если сервер профилей не найдёт в истории ранее доставленное сообщение - значит оно было удалено, о чём должна быть инфа в ответе на запрос и присвоен соответствующий статус. Дабы избежать дублей - сначала проверять их наличие в SQLite БД при отсутствии сервера профилей, а потом отображать в ОС. Всё, что не дочитано и не доотправлено временно можно хранить в SQLite БД.

По итогу сообщения должны иметь следующие статусы прогресса: отправка, доставлено до сервера профилей получателя, прочитано и удалено. Вспоминается анекдот. Если пацаны не умеют читать - они идут в думу. Там у них первое чтение, второе чтение, третье чтение. Они сидят и читают до тех пор, пока не поймут. Ещё был нормальный анекдот про чистописание, но я его не помню.