Hello Nil!
On Fri, 25 Aug 2023 at 07:25 +0300, you wrote to me:
AF>> Такой софт должен импортировать сообщения в свою базу,
AF>> предназначенную для таких специфичных действий.
NA> А вот и нет. Мне, лично, не симпатизируют все те разрабы, что
NA> засовывают сообщения в SQL, например. Засунули, свои какие-то там дела
NA> порешали, и всё, больше ни с кем не совместимо - пример тому JNode.
Значит ты любитель костылестроения.
NA> А тут, мы берём, чиста по спекам, и всё работает, и со всеми
NA> совместимы. Только не все спеки читают, и пуржиют, как им в голову
NA> взбредёт.
Изначально речь шла о сортировке, а не о пуржинге, и как ты себе представляешь
сортировку без смены номера сообщения?
Да и спеки никто не нарушает делая renumbering даже без сортировки. При
упаковке это нормальная история. А вот оставлять дыры в индексе ради
сохраниения номеров сообщений - это костыли, нужные только для работы
специфичного софта, который вместо того, чтобы использовать нормальную БД,
пытается работать с не предназначенной для таких целей JAM-базой.
AF>> Либо строить какой-то свой индекс,
NA> Ага, типа как ластрид файлик, который опциональный, но про него хоть
NA> знают все, и его обновляют (иногда). Так то я и full-text search
NA> индекс могу положить рядом, чтобы поиск работал сразу, но это всё
NA> НЕСОВМЕСТИМО.
Это и не должно быть совместимо, потому что нужно только одной специфичной
софтине. И класть это нужно рядом с этой софтиной, а не с JAM-базой.
AF>> Нельзя расчитывать на то, что у сообщения в базе (Jam, Squish)
AF>> есть какой-то перманентный абсолютный номер.
NA> Дану? В Сквише есть этот самый UMSGID (Unique Message Identifier).
Это не номер сообщения в общепринятом понятии. В JAM прямо в заголовке есть
MSGID, OADDRESS и DADDRESS, этого вполне достаточно для использования в
качестве уникальной сигнатуры.
NA> В Джаме есть номер сообщения в заголовках, но за константное время
NA> туда можно также добраться через BaseMsgNum прям.
Если быть точным, то BaseMsgNum нужен только для того, чтобы посчитать
относительный номер сообщения, зная абсолютный, чтобы через JDX найти позицию
заголовка в JHR и сделать туда fseek().
Я ещё раз хочу подчеркнуть, что BaseMsgNum в разговоре о том, что пуржинг
(точнее упаковка) может привести к изменению абсолютных номеров сообщений, не
играет вообще никакой роли. Это всего лишь часть механики по вычислению
относительного номера, зная абсолютный, и наоборот.
NA> Например, хаски под низом использует smapi библиотеку, и там
NA> постоянные вызовы MsgMsgnToUid и MsgUidToMsgn, не знаешь зачем?
Я с этой либой не знаком, поэтому ХЗ.
AF>> В теории, можно написать пуржилку, которая будет сохранять номера
AF>> писем, оставляя дырки в индексе, но такая пуржилка никому, кроме
AF>> держателей странного софта, не нужна, поэтому вряд ли кто-то
AF>> будет это делать.
NA> А знаешь сколько у разных утилит есть опций?
Для опций нужен код. Этот код кто-то должен написать. Я к тому, что никто такой
код писать не будет, потому что нафиг это не нужено. Ибо <тут известная цитата
про бедуинов>.
NA>>> После пуржинья, например, BaseMsgNum выставился в 5
AF>> После пуржинга он должен выставиться в 1 и больше никогда не
AF>> меняться вообще.
NA> Ну окей, в мире котором ты живёшь, там BaseMsgNum==1 всегда. Есть
NA> вариант, когда он не 1? Если ты начинаешь новую базу, то он 1, если
NA> продолжаешь старую, то уже не 1.
Нужно один раз делать упаковку такой старой базы, чтобы BaseMsgNum стал 1 и
больше никогда не менялся. Поменяются абсолютные номера сообщений, зато
относительные сохранятся (если не было удалений или сортировки).
NA> Пойдём от обратного. Если BaseMsgNum есть, и учавствует в арифметике
NA> номеров сообщений, значит оно кому-то надо.
Ты как будто бы вообще не читаешь, что я пишу. Не вижу смысла писать по кругу
одно и то же.
NA> Иначе бы такое поле не делали.
Его сделали когда-то давно, и его единственная задача - скрыть N сообщений с
начала базы. Например, чтобы поддерживать фиксированное максимальное количество
сообщений в базе без упаковки и пуржинга. Всё. Если у тебя в какой-то базе
BaseMsgNum не 1, значит когда-то давно у тебя был настроен лимит сообщений.
Если он у тебя всё ещё настроен, то регулярное изменение BaseMsgNum оправдано.
Если нет, то нужно упаковать базу и забыть об этом.
AF>> Всё верно, потому что если какой-то древний софт зачем-то меняет
AF>> BaseMsgNum, то любой другой софт должен это учитывать. Но при
AF>> пуржинге (а точнее при упаковке) оставлять BaseMsgNum отличным от
AF>> 1 - как минимум странно.
NA> Как минимум ты не понимешь юзкейс, почему BaseMsgNum может быть не 1.
Я понимаю, а ты точно понимаешь?
... Music Station BBS |
https://bbs.bsrealm.net | telnet://
bbs.bsrealm.net