= Сообщение: 2184 из 2457 =================================== RU.FTN.DEVELOP =
От : Nil A 2:5015/46 25 Aug 23 07:25:10
Кому : Alexey Fayans 25 Aug 23 07:25:10
Тема : BaseMsgNum в JAM
FGHI : area://RU.FTN.DEVELOP?msgid=2:5015/46+64e83412
На : area://RU.FTN.DEVELOP?msgid=2:5030/1997@fidonet+64e7a66e
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:5030/1997@fidonet+64e855ec
==============================================================================
* Originally in ru.fidonet.today
* Crossposted in ru.ftn.develop
Hello, Alexey!
Thursday August 24 2023 21:26, from Alexey Fayans -> Nil A:
AF>>> Это проблемы кривого софта типа SmapiNNTPd, а не пуржилки.
NA>> Пример, надо тебе написать софт, который сразу может прыгать на
NA>> 10ое сообщение из JAM базы. После пуржинья, предположим, это
NA>> сообщение стало 5ым. Линеный поиск сообщения по всей базе не
NA>> предлагать O(n).
AF> Такой софт должен импортировать сообщения в свою базу, предназначенную
AF> для таких специфичных действий.
А вот и нет. Мне, лично, не симпатизируют все те разрабы, что засовывают сообщения в SQL, например. Засунули, свои какие-то там дела порешали, и всё, больше ни с кем не совместимо - пример тому JNode.
А тут, мы берём, чиста по спекам, и всё работает, и со всеми совместимы.
Только не все спеки читают, и пуржиют, как им в голову взбредёт.
AF> Либо строить какой-то свой индекс,
Ага, типа как ластрид файлик, который опциональный, но про него хоть знают все, и его обновляют (иногда).
Так то я и full-text search индекс могу положить рядом, чтобы поиск работал сразу, но это всё НЕСОВМЕСТИМО.
AF> Нельзя расчитывать на то, что у сообщения в базе (Jam, Squish) есть
AF> какой-то перманентный абсолютный номер.
Дану? В Сквише есть этот самый UMSGID (Unique Message Identifier).
В Джаме есть номер сообщения в заголовках, но за константное время туда можно также добраться через BaseMsgNum прям.
Например, хаски под низом использует smapi библиотеку, и там постоянные вызовы MsgMsgnToUid и MsgUidToMsgn, не знаешь зачем?
AF> В теории, можно написать пуржилку, которая будет сохранять номера
AF> писем, оставляя дырки в индексе, но такая пуржилка никому, кроме
AF> держателей странного софта, не нужна, поэтому вряд ли кто-то будет это
AF> делать.
А знаешь сколько у разных утилит есть опций? Например, rsync, скопировать слева на право, казалось бы, а man rsync ты зачитаешься. Я про то, что кто как хочет, так и пуржит, только дайте опции людям. Людям, с потребностями разными. А которые без потребностей, тем и дефолт софйдёт какой-нибудь.
NA>> После пуржинья, например, BaseMsgNum выставился в 5
AF> После пуржинга он должен выставиться в 1 и больше никогда не меняться
AF> вообще.
Ну окей, в мире котором ты живёшь, там BaseMsgNum==1 всегда. Есть вариант, когда он не 1?
Если ты начинаешь новую базу, то он 1, если продолжаешь старую, то уже не 1.
Пойдём от обратного. Если BaseMsgNum есть, и учавствует в арифметике номеров сообщений, значит оно кому-то надо. Иначе бы такое поле не делали.
NA>> В спеке он есть. Нормальный софт всегда высчитывает номер
NA>> сообщения прибавляя BaseMsgNum.
AF> Всё верно, потому что если какой-то древний софт зачем-то меняет
AF> BaseMsgNum, то любой другой софт должен это учитывать. Но при пуржинге
AF> (а точнее при упаковке) оставлять BaseMsgNum отличным от 1 - как
AF> минимум странно.
Как минимум ты не понимешь юзкейс, почему BaseMsgNum может быть не 1.
AF> В спеке указан только один юзкейс для этого - удалить первые N
AF> сообщений в базе, точнее, сделать их "недоступными". Это явно было
AF> придумано до того, как сделали soft delete. Сейчас в этом смысла нет.
Верно. Правильная работа функций MsgMsgnToUid и MsgUidToMsgn возможно только тогда, когда там будут дырки, если сообщения стёрли. Удалять получается только слева, далее приходится осталять дырки.
Про smapi, кстати. Там MsgMsgnToUid/MsgUidToMsgn притащили из Сквиша (Squish MSGAPI, если уж название раскрывать польностью), но когда универсальный API натянули и на Jam (аля-виртуальные функции в C, или как в Джаве говорят - интерфейсы), то эти функции работают не корректно тоже, ещё и зачем-то весь индекс в память вычитывают, ДОСа на них нету.
Best Regards, Nil
--- GoldED+/LNX 1.1.5
* Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
|
