Мысли по поводу: ID в адресах, истории, сообщений, вложений

Устаревшие и неактуальные темы, которые содержат полезную информацию.
Закрыто
x2088
Сообщения: 36
Зарегистрирован: Чт май 05, 2022 2:33 pm

Мысли по поводу: ID в адресах, истории, сообщений, вложений

Сообщение x2088 »

Формат адресов хотелось бы иметь приближенный к жабе. В следующем формате:
Контакт: 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, цифра", напоминаю про типографские раскладки до кучи, если что.
alex
Сообщения: 18
Зарегистрирован: Вт мар 29, 2022 2:20 pm

Re: Мысли по поводу: ID в адресах, истории, сообщений, вложений

Сообщение alex »

x2088 писал(а): Пн май 09, 2022 10:12 pm Галку для локального сохранения файлов по прямым ссылкам тоже надо - ибо сервер сёдня есть, а завтра нету и что там было по ссылке было уже непонятно.
Имхо, автоскачивание, по крайней мере по прямым ссылкам, - не есть хорошо, как минимум по 2 поводам:
  • файлы могут быть очень большие и, возможно, ненужные пользователю (например, в общей конфе)
  • файлы могут быть заражены (в файловом сервере возможно хотя бы ограничить разрешенные типы файлов)
x2088
Сообщения: 36
Зарегистрирован: Чт май 05, 2022 2:33 pm

Re: Мысли по поводу: ID в адресах, истории, сообщений, вложений

Сообщение x2088 »

Алекс, галка вроде уже была; речь про кидаемые в чат прямые ссылки, которые могут подгружаться автоматически при наличии в скине ресурса 500.гиф, если я за 8 лет ничё не забыл - пишу по памяти - авто сохранение вот этого всего, что было уже подгружено.
x2088
Сообщения: 36
Зарегистрирован: Чт май 05, 2022 2:33 pm

Re: Мысли по поводу: ID в адресах, истории, сообщений, вложений

Сообщение x2088 »

Три раза забыл дописать уточнение.

Если интерфейс клиента был закрыт не читая сообщения - сервер профилей об этом никак не узнает, поэтому при запуске или выходе из антибосса (можно и собственный хоткей сделать) серверу профилей нужно отправлять запрос "Есть что нового?" для повторной отсылки непрочитанных сообщений с игнорированием списков рассылок. Слежением за возможными дублями тут уже должен заниматься клиент. Как фичу в клиенте отправлять запрос кнопкой "Отправить" при пустом поле ввода сообщения.
x2088
Сообщения: 36
Зарегистрирован: Чт май 05, 2022 2:33 pm

Re: Мысли по поводу: ID в адресах, истории, сообщений, вложений

Сообщение x2088 »

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

По поводу больших файлов - политики использования дискового пространства на сервере никто не отменял, до кучи даже если сервер профилей превратится в облако - в облаке один хрен есть ограничение на общий объём файлов. Что не влазит в политики - удалять по таймауту или вообще не давать сохранять там. На локальном сервере профилей, установленном на компе с клиентом - можно делать чё хошь, если опять же нет ограничений на использование дискового пространства.
x2088
Сообщения: 36
Зарегистрирован: Чт май 05, 2022 2:33 pm

Re: Мысли по поводу: ID в адресах, истории, сообщений, вложений

Сообщение x2088 »

У общих конф есть (даже не должна быть) своя папка для хранения вложений и всё должно скачиваться туда, а не делаться 873234248396829746 копий - каждому по копии в профиле. Если что-то никому не нужно и это кидает кто-то определённый - есть волшебная рыба - лещ, а если он с одного раза не поможет - поможет др волшебное животное - бегущий лось.
x2088
Сообщения: 36
Зарегистрирован: Чт май 05, 2022 2:33 pm

Re: Мысли по поводу: ID в адресах, истории, сообщений, вложений

Сообщение x2088 »

Забыл про 1 момент, не опять, а снова. На глобальном сервере профилей история будут храниться не в профиле пользователя, поэтому формат будет таким:
* Диалоги: ./History /acc@host.net_acc@srv.com /yyyy.mm.dd_hh.mm.ss_acc@host.net_acc@srv.com.db (личный список контактов)
* Конфы: ./History /room#srv.net /#id1_id2 /yyyy.mm.dd_hh.mm.ss_id1_id2.db (отдельная подпапка для личных сообщений каждой пары id)

* Конфы: ./History /room#srv.net /yyyy.mm.dd_hh.mm.ss_room#srv.net.db (общий чат)
* Конфы: ./History /room#srv.net /@subject /yyyy.mm.dd_hh.mm.ss_room#srv.net.db (обсуждения)

Здесь нет подпапок отправителя и вложенной подпапки получателя, имя файла содержит оба адреса и формат SQL БД. Данный вид хранения можно называть диалогами. Логины или id в паре сортируются в алфавитном порядке. Внутри БД имеется 2 таблицы. В первой - пара логинов или id, в случае с id должна быть дата-время их генерации и до кучи время создания файла бд с диалогом. На главном сервере должен храниться список сопоставления логина и id с учётом истории их смены пользователем. Ели быть точным, то запрос этой инфы должен быть только у главного сервера, даже не в правах, а в коде. Во второй - собственно сам диалог, строки в следующем формате - дата сообщения, статус сообщения у первого пользователя, статус сообщения у второго пользователя, текст сообщения. ИД сообщения не нужно - им может быть время со всеми восьмью его байтами, если время повторяется - значит в следующей строке таблицы продолжение длинного сообщения, а чтобы не добавлять колонку с номером куска сообщения - прибавлять 0,000001 секунды (1 тик) к каждому следующему куску.

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

С файлами есть 2 варианта - мелкий и наглухо глобальный:

* Файлы, диалоги: ./Files /acc@host.net /filename (папка залившего файл, историю скачиваний хранить отдельно в бд)
* Файлы, конфы, общее: ./Files /room#srv.net /!attached /filename
* Файлы, конфы, личные: ./Files /room#srv.net /id /filename (папка залившего файл, историю скачиваний хранить отдельно в бд)

В БД две таблицы: первая - имя файла, число уникальных скачиваний; вторая - логин/id скачавшего, время последнего скачивания. Хранить дубли скачиваний смысла не вижу.

Горбальный: ./Files /%sha1%.sha1
Вспомогательные файлы: ./Files /!Info /%sha1%.txt
Загрузка при совпадении имён/хеша: ./Files /00000000 /%sha1%.sha1
Коллизии: ./Files /00000001 /%sha1%.sha1 (номер подпапки по порядку, внутри все имеющиеся файлы с коллизией хешей, в случае повторной коллизии создаётся подпапка 00000002 и т.д.)

Как вариант можно генерировать читаемые человеком без лишнего гуя вспомогательные файлы в виде %sha1%.txt, внутри хранить имя и историю скачиваний. Операционная система позволяет искать инфу внутри текстовых файлов без заглядывания в каждый. Хеши должен считать клиент при заливке. Как вариант можно использовать др тип хешей, md5 или sha3 в идеале (нет коллизий). В случае коллизий запихивать файл в подпапку, если содержимое действительно разное.

В БД три таблицы: первая - загрузивший, имя файла, размер, дата загрузки, дата правки файла, хеш, число уникальных скачиваний, маркер 1 байт (свистелки по поводу избранности файла); вторая - логин скачавшего, время последнего скачивания, число скачиваний; третья - виртуальная древовидная структура папок с корнем от логина, в которой указано как и что распихано по этим виртуальным папкам.

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

По поводу заливки 100500 копий файлов одного и того же. Да, его не будет вообще, но я предлагаю делить вес данных файлов на всех, кто добавил себе файл в своё облако - это будет справедливо. Кто-то может надобавлять на весь выделенный объём чужих файлов и исчерпать всё своё место, а кто-то заливает только своё. Только реально в облаке тратятся считанные байты при добавлении копий файлов, а не их реальный вес.
Закрыто