= Сообщение: 2186 из 2457 =================================== RU.FTN.DEVELOP =
От : Nil A 2:5015/46 25 Aug 23 17:28:44
Кому : Alexey Fayans 25 Aug 23 17:28:44
Тема : BaseMsgNum в JAM
FGHI : area://RU.FTN.DEVELOP?msgid=2:5015/46+64e8c05a
На : area://RU.FTN.DEVELOP?msgid=2:5030/1997@fidonet+64e855ec
= Кодировка сообщения определена как: CP866 ==================================
==============================================================================
Hello, Alexey!
Friday August 25 2023 09:15, from Alexey Fayans -> Nil A:
NA>> А вот и нет. Мне, лично, не симпатизируют все те разрабы, что
NA>> засовывают сообщения в SQL, например. Засунули, свои какие-то там
NA>> дела порешали, и всё, больше ни с кем не совместимо - пример тому
NA>> JNode.
AF> Значит ты любитель костылестроения.
Ну, если ты считаешь, что все эти фидошные базы - это костыли, то я с тобой, конечно же соглашусь. Например, чего только стоит поиск адреса отправителя. Причём, для нетмейлов алгоритм один, для эх другой. Но т.к. все мы тут сегодня собрались, то значит фидо и фидобазы всё ещё огонь.
AF> Изначально речь шла о сортировке, а не о пуржинге, и как ты себе
AF> представляешь сортировку без смены номера сообщения?
А вот, кстати, проблема тоже. Зачем мне каким-то образом сортировать сообщения в базе, т.е. как они там физически последовательно записаны в файле? Меня устраивает физический порядок следования записей, как они туда попадала - это же база просто.
Ааа.. наверное почтовая программа не умеет сортировать так, как мне хотелось бы, а только последовательно из файла базы показывает сообщения, поэтому физческий порядок следования важен? А если я тредами показываю, у меня там сортировка другая, а если я по имени автора, а если у меня скоринг и сортируется хитро? Нет, мы будет сортировать сообщения только тем "кашерным" способом, что нам предложил Стас своим скриптом.
AF> Да и спеки никто не нарушает делая renumbering даже без сортировки.
Нет, не нарушает. Просто он создаёт _новую_ базу. А кто имеет какие-то "индексы" к старой базе, то он страдает.
AF> Если быть точным, то BaseMsgNum нужен только для того, чтобы посчитать
AF> относительный номер сообщения, зная абсолютный, чтобы через JDX найти
AF> позицию заголовка в JHR и сделать туда fseek().
Верно. Можно прыгать на абсолютный номер сообщения за O(1), прям пользуясь спеком, из-коробки. А msdid+oadress+... связка, этож надо сначала построить индекс, хотя дуполовка так и делает.
AF> Я ещё раз хочу подчеркнуть, что BaseMsgNum в разговоре о том, что
AF> пуржинг (точнее упаковка) может привести к изменению абсолютных
AF> номеров сообщений, не играет вообще никакой роли. Это всего лишь часть
AF> механики по вычислению относительного номера, зная абсолютный, и
AF> наоборот.
Верно. Механизм есть, и он должен работать. Вопрос. Откуда у тебя изначально берётся абсолютный номер сообщения, что тебе надо пересчитывать на относительный? Значит тебе абсолютный номер зачем-то таки нужен?
NA>> Например, хаски под низом использует smapi библиотеку, и там
NA>> постоянные вызовы MsgMsgnToUid и MsgUidToMsgn, не знаешь зачем?
AF> Я с этой либой не знаком, поэтому ХЗ.
Ну окей, не пользуешься hpt, но голдедом то пользуешься? Там это в goldlib/gall/gutltag.cpp файле.
// Return the tag number corresponding to a relative tag number.
uint32_t GTag::CvtReln(uint __reln)
// Return the relative tag number corresponding to a tag number.
uint GTag::ToReln(uint32_t __tagn, int __closest)
NA>> Как минимум ты не понимешь юзкейс, почему BaseMsgNum может быть
NA>> не 1.
AF> Я понимаю, а ты точно понимаешь?
А я вопросом на вопрос ;-) Зачем тебе может потребоваться абсолютный номер? Читай сообщения всю дорогу по относительному номеру, просто как смещение в файле.
Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
|
