Мысли по поводу: ID в адресах, истории, сообщений, вложений
Добавлено: Пн май 09, 2022 10:12 pm
Формат адресов хотелось бы иметь приближенный к жабе. В следующем формате:
Контакт: acc@host.net/resource
Конфа + контакт: room#srv.net/id
Транспорт: acc@host.net%protocol.srv.net (да, в жабе @ и % наоборот, но так привычнее)
Теперь собственно то, зачем эта тема. ID = текстовая строка или 36-ричное 8-иразрядное число, рассматривайте как хотите. Латинский алфавит и цифры.
36^8 = 2 821 109 907 456 вариантов, если вдруг этого будет мало для какой-нить сквозной глобальной нумерации, можно сделать 10 разрядов и/или использовать чувствительность к регистру - 36^10 = 3 656 158 440 062 976, 62^8 = 218 340 105 584 896, 62^10 = 839 299 365 868 340 224. В любом случае использовать целое число 8 байт без знака для хранения - нормальный вариант, конвертация в число с др основанием и сохранение результата в профиле делается однократно клиентом, а серверу можно отправлять оба значения, дабы снизить его вычисления. Незначащие разряды заполнять нулями, при преобразовании в текстовую строку возвращать только последние самые правые символы строки в нужном количестве. Использовать рандомный 128 бит SID в HEX виде с дефисами и скобками - перебор, хотя да - это строчка кода в современных языках программирования, поэтому этим постоянно пользуются, не обращая внимания на кровь-из-глаз при чтении пользователем.
Когда пользователь логинется в клиенте и создаётся профиль с настройками клиента - генерируется ID, который используется как ресурс и адрес контакта в конфе. В случае с ресурсом - его можно править в ручную как угодно - по факту происходит выбор между пустой строкой и ID, в результате присваиваетcя ID, а если строка не пустая - введённое пользователем значение. Если вдруг в конфе уже имеется данный ID - сервер возвращает следующую по порядку строку/цифру, которую использует клиент. Сервер генерацией всего этого не занимается в принципе. Если пользователь по какой-то причине хочет сменить ID - он в ручную жмёт кнопку в настройках клиента и получает новую строку, всё. Сервер запрашивает ID и сопоставляет его с адресом контакта в сети. В децентрализованной сети возможны коллизии, но едва ли это имеет значение. Поиск по ID может быть полезен для глобальных сетей, когда нужно найти кого-то известного в публичных комнатах. В локальных сетях при текучке по старому ID можно определять кто теперь всем этим занимается вместо старого сотрудника, даже если всё остальное в профиле было изменено. На стороне сервера из админки должна быть возможность править ID как вздумается.
Это же ID предлагается в качестве дефолтного значения для room, сервер возвращает первое свободное значение в качестве адреса конфы, начиная с заданной строки/числа. Дефолтное значение можно отредактировать читаемым человеком текстом как обычно, нормальное название комнаты можно придумывать сколь угодно долго, до кучи часто оно и не нужно. Если всё таки захотелось переименовать комнату - должна быть возможность сделать это в любой момент времени, даже после её создания. Поэтому на программном уровне адресация больше будет использовать ID, а не отображаемый адрес, который будет альтернативой. Ник не заменяет ID, если ники совпадают - отображать диалог смены ника и добавлять двузначное число по порядку в конце, возможно через пробел, начиная с 00. Как вариант на сервере должна быть возможность разрешения дублирования ников в конфе. В организациях используются настоящие имена и полные тёски никем не отменялись, даже с совпадающим годом рождения. Лично я знаю такое - веселье в наркологическом диспансере при этом обеспечено - справка о том, шо ты не жираф не поможет, только личное одновременное присутствие обоих с паспортами, да они были знакомы (хорошо, шо это было не со мной).
Это же ID в ресурсе. Современные сети позволяют множественный логин, но отправляют сообщения сразу на все активные подключения, что очень плохо. Для отправки на все подключения можно или не указывать ресурс (сервер сам должен определиться чё делать и как быть, по дефолту такое надо отправлять на последний активный ресурс, а потом уже продолжать рассылку или забивать на это) или явно указывать как ноль (сервер отправляет сообщение по каждому подключению для данного акка). Рассылкой сообщений по ресурсам должен сервер профилей, а не общий сервер - он отсылает сообщение 1 раз серверу профилей, получает подтверждение старта рассылки и на этом больше не занимается данной хренью. Пользователь может указать пояснение для ресурса читаемое человеком как title, сам ID никуда не девается.
Лично я считаю, что рассылка на все подключенные ресурсы/сессии - ересь. Это тратит ресурсы сервера почти в пустую поскольку хранением истории и доступом к ней должен заниматься сервер профилей. Любой пользователь в состоянии прочитать историю со своего сервера профилей как архивную без всяких синхронизаций. Здесь можно просто сделать левую иконку "История: имеются новые сообщения" для наглядности. Едва ли это будет сильно востребовано, поскольку пользователь всё это по большей части будет читать сразу на разных клиентах под разными сессиями подключения. До кучи при явном указании единственного ресурса куда нужно отправить сообщение может иметь вполне полезное назначение. Получатель прочитает сообщение только в определённом географическом месте, где нужно сделать то, что просится в сообщении, поэтому шанс, что это сообщение тут же будет забыто по прочтению и ничего не будет сделано куда ниже.
Теперь по поводу несуществующих ресурсов и принудительной отправки сообщений на строго указанный ресурс. В жабе такое уходит в оффлайн до подключения указанного ресурса, запросить это можно было только по ad-hoc, на который обычно клали болт, до кучи число офлайн сообщений ограничено на сервере, поэтому похерить такое сообщение проще пареной репы. Я считаю, что подобные сообщения должны отправляться серверу профилей с установленным флагом "оффлайн", а пользователь должен иметь возможность их чтения сразу только в истории, но это не значит, что сервер профилей после этого не должен отправить сообщение клиенту как новое, при подключении указанного при отправке ресурса. Данное поведение не будет конфликтовать с обычной отправкой на строго указанный ресурс, чтобы пользователь прочитал сообщение только придя на строго определённое место ещё раз.
Сообщение отправлено на последний активный ресурс, но пользователь его не прочитал. Статус сообщения "прочитано" в этом случае сервер профилей не получает и отправляет сообщения последнему новому/сменившемуся активному ресурсу до тех пор, пока они не будут прочитаны в интерфейсе клиента. Тут требуется хранить список ID ресурсов куда сообщения уже отправлялись, дабы не отправлять их туда ещё раз.
В завершение. Рассылка сообщений по сессиям должна быть сначала на последний активный ресурс, для чего клиент при любом действии с интерфейсом должен однократно отправлять уведомление серверу о своей активации и присвоением максимального приоритета, а затем в порядке убывания, в случае нескольких максимумов - на каждый. Клиент с минимальным приоритетом ресурса сообщения не получает в принципе - только чтение в истории, то есть сервер профилей не отправляет сообщения клиенту / в интерфейс клиента. Само указание ресурса должно означать, что сообщение должно быть отправлено именно на этот ресурс, а не на каждый или последний активный. Данный концепт не совпадает с концептом жабы. В окне истории, возможно, было бы так же удобно устанавливать приоритет, устанавливая его в минимум или наоборот повышая, дабы не лезть в настройки статуса/подключения. Паковать приоритет в старшие или младшие разряды ID не нужно, да и при 62^10 там остаётся только 4 бита.
Формат хранения истории в текстовом виде в клиенте хотелось бы в нормальном виде как:
* Диалоги: ./History /acc@host.net /acc@srv.com /yyyy.mm.dd_hh.mm.ss_acc@srv.com.txt (личный список контактов)
* Конфы: ./History /acc@host.net /room#srv.net /yyyy.mm.dd_hh.mm.ss_room#srv.net.txt (общий чат)
* Конфы: ./History /acc@host.net /room#srv.net /@subject /yyyy.mm.dd_hh.mm.ss_room#srv.net.txt (отдельная подпапка для обсуждений определённого вопроса или темы, для каждой своя - это выборка из общей истории без флуда, вопрос-ответ, модерируемая участниками конфы)
* Конфы: ./History /acc@host.net /room#srv.net /#id /yyyy.mm.dd_hh.mm.ss_id.txt (отдельная подпапка для каждого id для личных сообщений)
* Конфы: ./History /acc@host.net /room#srv.net /!attached /#id /filename (папка для локального хранения выкладываемых файлов при их скачивании, клиент, неплохо иметь возможность удаления скачанных вложений из окна истории, #id и filename в окне истории должны быть фильтрами, по дефолту показывается всё содержимое всех подпапок в !attached)
В интерфейсе для выбора тома выпадающий список и/или календарик, выбирающий самый старый том, в котором содержится указанная дата. Всё это без этих дурацких папок "Archive", где всё насыпом, впрочем как и в папке истории было везде и всегда. Дата+время в имени файла - самое первое сообщение в файле при нарезке истории на тома. Первый логин - отправитель, второй логин - получатель, есть поддержка мультиакков в структуре папок. Можно и в html хранить - для выкладывания в инете может быть хорошо, хотя там тазве шо картиночки можно будет видеть сразу, а так те же яйца. Галку для локального сохранения файлов по прямым ссылкам тоже надо - ибо сервер сёдня есть, а завтра нету и что там было по ссылке было уже непонятно. Сохранять при получении сообщения, ну, для старых сообщений без скачивания файлов можно, в ручную или полуавтоматом, если сообщению максимум неделя. Фильтр поиска по истории: login/id (список), период, искомое. Сюда же кнопку для открытия папки хранения истории текущего контакта или конфы. В принципе получается сервер профилей должен иметь три сериализатора для сохранения истории: txt, html (локальное хранение на пользовательском компе) и БД (глобальное хранение на сервере или удалённо в сети).
ЗЫЖ для поиска конф по хеш тегам альтернативные символы для # должны быть ++ , == , `` и ~~ в начале строки - ибо нефиг, не каждый язык позволяет печатать решётку без переключения раскладки, а печатать её кодами символов - для извратов. Как вариант последовательный хоткей для вставки разных символов юникода из пользовательского списка - там может быть уже что угодно, да, мне бы такое пригодилось - я использую диакритику при печати транскрипции, у меня в ворде забиты хоткеи вида "alt+q, цифра", напоминаю про типографские раскладки до кучи, если что.
Контакт: acc@host.net/resource
Конфа + контакт: room#srv.net/id
Транспорт: acc@host.net%protocol.srv.net (да, в жабе @ и % наоборот, но так привычнее)
Теперь собственно то, зачем эта тема. ID = текстовая строка или 36-ричное 8-иразрядное число, рассматривайте как хотите. Латинский алфавит и цифры.
36^8 = 2 821 109 907 456 вариантов, если вдруг этого будет мало для какой-нить сквозной глобальной нумерации, можно сделать 10 разрядов и/или использовать чувствительность к регистру - 36^10 = 3 656 158 440 062 976, 62^8 = 218 340 105 584 896, 62^10 = 839 299 365 868 340 224. В любом случае использовать целое число 8 байт без знака для хранения - нормальный вариант, конвертация в число с др основанием и сохранение результата в профиле делается однократно клиентом, а серверу можно отправлять оба значения, дабы снизить его вычисления. Незначащие разряды заполнять нулями, при преобразовании в текстовую строку возвращать только последние самые правые символы строки в нужном количестве. Использовать рандомный 128 бит SID в HEX виде с дефисами и скобками - перебор, хотя да - это строчка кода в современных языках программирования, поэтому этим постоянно пользуются, не обращая внимания на кровь-из-глаз при чтении пользователем.
Когда пользователь логинется в клиенте и создаётся профиль с настройками клиента - генерируется ID, который используется как ресурс и адрес контакта в конфе. В случае с ресурсом - его можно править в ручную как угодно - по факту происходит выбор между пустой строкой и ID, в результате присваиваетcя ID, а если строка не пустая - введённое пользователем значение. Если вдруг в конфе уже имеется данный ID - сервер возвращает следующую по порядку строку/цифру, которую использует клиент. Сервер генерацией всего этого не занимается в принципе. Если пользователь по какой-то причине хочет сменить ID - он в ручную жмёт кнопку в настройках клиента и получает новую строку, всё. Сервер запрашивает ID и сопоставляет его с адресом контакта в сети. В децентрализованной сети возможны коллизии, но едва ли это имеет значение. Поиск по ID может быть полезен для глобальных сетей, когда нужно найти кого-то известного в публичных комнатах. В локальных сетях при текучке по старому ID можно определять кто теперь всем этим занимается вместо старого сотрудника, даже если всё остальное в профиле было изменено. На стороне сервера из админки должна быть возможность править ID как вздумается.
Это же ID предлагается в качестве дефолтного значения для room, сервер возвращает первое свободное значение в качестве адреса конфы, начиная с заданной строки/числа. Дефолтное значение можно отредактировать читаемым человеком текстом как обычно, нормальное название комнаты можно придумывать сколь угодно долго, до кучи часто оно и не нужно. Если всё таки захотелось переименовать комнату - должна быть возможность сделать это в любой момент времени, даже после её создания. Поэтому на программном уровне адресация больше будет использовать ID, а не отображаемый адрес, который будет альтернативой. Ник не заменяет ID, если ники совпадают - отображать диалог смены ника и добавлять двузначное число по порядку в конце, возможно через пробел, начиная с 00. Как вариант на сервере должна быть возможность разрешения дублирования ников в конфе. В организациях используются настоящие имена и полные тёски никем не отменялись, даже с совпадающим годом рождения. Лично я знаю такое - веселье в наркологическом диспансере при этом обеспечено - справка о том, шо ты не жираф не поможет, только личное одновременное присутствие обоих с паспортами, да они были знакомы (хорошо, шо это было не со мной).
Это же ID в ресурсе. Современные сети позволяют множественный логин, но отправляют сообщения сразу на все активные подключения, что очень плохо. Для отправки на все подключения можно или не указывать ресурс (сервер сам должен определиться чё делать и как быть, по дефолту такое надо отправлять на последний активный ресурс, а потом уже продолжать рассылку или забивать на это) или явно указывать как ноль (сервер отправляет сообщение по каждому подключению для данного акка). Рассылкой сообщений по ресурсам должен сервер профилей, а не общий сервер - он отсылает сообщение 1 раз серверу профилей, получает подтверждение старта рассылки и на этом больше не занимается данной хренью. Пользователь может указать пояснение для ресурса читаемое человеком как title, сам ID никуда не девается.
Лично я считаю, что рассылка на все подключенные ресурсы/сессии - ересь. Это тратит ресурсы сервера почти в пустую поскольку хранением истории и доступом к ней должен заниматься сервер профилей. Любой пользователь в состоянии прочитать историю со своего сервера профилей как архивную без всяких синхронизаций. Здесь можно просто сделать левую иконку "История: имеются новые сообщения" для наглядности. Едва ли это будет сильно востребовано, поскольку пользователь всё это по большей части будет читать сразу на разных клиентах под разными сессиями подключения. До кучи при явном указании единственного ресурса куда нужно отправить сообщение может иметь вполне полезное назначение. Получатель прочитает сообщение только в определённом географическом месте, где нужно сделать то, что просится в сообщении, поэтому шанс, что это сообщение тут же будет забыто по прочтению и ничего не будет сделано куда ниже.
Теперь по поводу несуществующих ресурсов и принудительной отправки сообщений на строго указанный ресурс. В жабе такое уходит в оффлайн до подключения указанного ресурса, запросить это можно было только по ad-hoc, на который обычно клали болт, до кучи число офлайн сообщений ограничено на сервере, поэтому похерить такое сообщение проще пареной репы. Я считаю, что подобные сообщения должны отправляться серверу профилей с установленным флагом "оффлайн", а пользователь должен иметь возможность их чтения сразу только в истории, но это не значит, что сервер профилей после этого не должен отправить сообщение клиенту как новое, при подключении указанного при отправке ресурса. Данное поведение не будет конфликтовать с обычной отправкой на строго указанный ресурс, чтобы пользователь прочитал сообщение только придя на строго определённое место ещё раз.
Сообщение отправлено на последний активный ресурс, но пользователь его не прочитал. Статус сообщения "прочитано" в этом случае сервер профилей не получает и отправляет сообщения последнему новому/сменившемуся активному ресурсу до тех пор, пока они не будут прочитаны в интерфейсе клиента. Тут требуется хранить список ID ресурсов куда сообщения уже отправлялись, дабы не отправлять их туда ещё раз.
В завершение. Рассылка сообщений по сессиям должна быть сначала на последний активный ресурс, для чего клиент при любом действии с интерфейсом должен однократно отправлять уведомление серверу о своей активации и присвоением максимального приоритета, а затем в порядке убывания, в случае нескольких максимумов - на каждый. Клиент с минимальным приоритетом ресурса сообщения не получает в принципе - только чтение в истории, то есть сервер профилей не отправляет сообщения клиенту / в интерфейс клиента. Само указание ресурса должно означать, что сообщение должно быть отправлено именно на этот ресурс, а не на каждый или последний активный. Данный концепт не совпадает с концептом жабы. В окне истории, возможно, было бы так же удобно устанавливать приоритет, устанавливая его в минимум или наоборот повышая, дабы не лезть в настройки статуса/подключения. Паковать приоритет в старшие или младшие разряды ID не нужно, да и при 62^10 там остаётся только 4 бита.
Формат хранения истории в текстовом виде в клиенте хотелось бы в нормальном виде как:
* Диалоги: ./History /acc@host.net /acc@srv.com /yyyy.mm.dd_hh.mm.ss_acc@srv.com.txt (личный список контактов)
* Конфы: ./History /acc@host.net /room#srv.net /yyyy.mm.dd_hh.mm.ss_room#srv.net.txt (общий чат)
* Конфы: ./History /acc@host.net /room#srv.net /@subject /yyyy.mm.dd_hh.mm.ss_room#srv.net.txt (отдельная подпапка для обсуждений определённого вопроса или темы, для каждой своя - это выборка из общей истории без флуда, вопрос-ответ, модерируемая участниками конфы)
* Конфы: ./History /acc@host.net /room#srv.net /#id /yyyy.mm.dd_hh.mm.ss_id.txt (отдельная подпапка для каждого id для личных сообщений)
* Конфы: ./History /acc@host.net /room#srv.net /!attached /#id /filename (папка для локального хранения выкладываемых файлов при их скачивании, клиент, неплохо иметь возможность удаления скачанных вложений из окна истории, #id и filename в окне истории должны быть фильтрами, по дефолту показывается всё содержимое всех подпапок в !attached)
В интерфейсе для выбора тома выпадающий список и/или календарик, выбирающий самый старый том, в котором содержится указанная дата. Всё это без этих дурацких папок "Archive", где всё насыпом, впрочем как и в папке истории было везде и всегда. Дата+время в имени файла - самое первое сообщение в файле при нарезке истории на тома. Первый логин - отправитель, второй логин - получатель, есть поддержка мультиакков в структуре папок. Можно и в html хранить - для выкладывания в инете может быть хорошо, хотя там тазве шо картиночки можно будет видеть сразу, а так те же яйца. Галку для локального сохранения файлов по прямым ссылкам тоже надо - ибо сервер сёдня есть, а завтра нету и что там было по ссылке было уже непонятно. Сохранять при получении сообщения, ну, для старых сообщений без скачивания файлов можно, в ручную или полуавтоматом, если сообщению максимум неделя. Фильтр поиска по истории: login/id (список), период, искомое. Сюда же кнопку для открытия папки хранения истории текущего контакта или конфы. В принципе получается сервер профилей должен иметь три сериализатора для сохранения истории: txt, html (локальное хранение на пользовательском компе) и БД (глобальное хранение на сервере или удалённо в сети).
ЗЫЖ для поиска конф по хеш тегам альтернативные символы для # должны быть ++ , == , `` и ~~ в начале строки - ибо нефиг, не каждый язык позволяет печатать решётку без переключения раскладки, а печатать её кодами символов - для извратов. Как вариант последовательный хоткей для вставки разных символов юникода из пользовательского списка - там может быть уже что угодно, да, мне бы такое пригодилось - я использую диакритику при печати транскрипции, у меня в ворде забиты хоткеи вида "alt+q, цифра", напоминаю про типографские раскладки до кучи, если что.