1. Forum
  2. FidoNet Russia
  3. RU.FTN.DEVELOP

  • BaseMsgNum в JAM

    From Nil A@2:5015/46 to Alexey Fayans on Thu Aug 24 16:40:48 2023
    * Originally in ru.fidonet.today
    * Crossposted in ru.ftn.develop
    Hello, Alexey!

    Thursday August 24 2023 07:47, from Alexey Fayans -> Nil A:

    Притензия в том, что создаётся новый файл с базой, в котором
    нумерация $BaseMsgNum начнётся заново, а это значит всякие
    ништяки, типа SmapiNNTPd поломаются, потому что не смогут сразу
    прыгнуть на нужный номер, потому что базовый номер съехал.
    Это проблемы кривого софта типа SmapiNNTPd, а не пуржилки.

    Пример, надо тебе написать софт, который сразу может прыгать на 10ое сообщение из JAM базы. После пуржинья, предположим, это сообщение стало 5ым. Линеный поиск сообщения по всей базе не предлагать O(n).

    Упаковать JAM базу без сброса BaseMsgNum, наверное, возможно, но это крайне тупо.

    Решение в том, что я хочу прыгнуть не на 10ое сообщение порядковое в базе, а именно 10ое. После пуржинья, например, BaseMsgNum выставился в 5, значит, чтобы добраться до 10го сообщения, мне надо прыгнуть сразу на 5ое порядковое. Это O(1) сложность.

    Правда, тут ещё есть нюанс - удалённые сообщения (дырки) приходится оставлять. Само тело сообщения можно не хранить, но индекс нужен с дырками. Получается, что пуржить удалённые письма можно только сначала.

    Кстати, примерно также работает Usenet. Он тебе говорит от кого сообщения у него в базе есть и до кокого, и сколько их всего, и разница может не быть равна сколько всего, потому что дырки.

    Вообще, BaseMsgNum - это рудимент, нормальный софт его не трогает.

    В спеке он есть. ормальный софт всегда высчитывает номер сообщения прибавляя BaseMsgNum. Если появились новопейсатели, которым хочется на каком-нибудь модном языке типа Go за два вечера там что-то набрасать, то для себя им, пусть они не трогают этот рудимент.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5
    * Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
  • From Nil A@2:5015/46 to Alexey Fayans on Fri Aug 25 07:25:10 2023
    * Originally in ru.fidonet.today
    * Crossposted in ru.ftn.develop
    Hello, Alexey!

    Thursday August 24 2023 21:26, from Alexey Fayans -> Nil A:

    Это проблемы кривого софта типа SmapiNNTPd, а не пуржилки.
    Пример, надо тебе написать софт, который сразу может прыгать на
    10ое сообщение из JAM базы. После пуржинья, предположим, это
    сообщение стало 5ым. Линеный поиск сообщения по всей базе не
    предлагать O(n).

    Такой софт должен импортировать сообщения в свою базу, предназначенную
    для таких специфичных действий.

    А вот и нет. Мне, лично, не симпатизируют все те разрабы, что засовывают сообщения в SQL, например. Засунули, свои какие-то там дела порешали, и всё, больше ни с кем не совместимо - пример тому JNode.

    А тут, мы берём, чиста по спекам, и всё работает, и со всеми совместимы.
    Только не все спеки читают, и пуржиют, как им в голову взбредёт.

    Либо строить какой-то свой индекс,

    Ага, типа как ластрид файлик, который опциональный, но про него хоть знают все, и его обновляют (иногда).
    Так то я и full-text search индекс могу положить рядом, чтобы поиск работал сразу, но это всё ЕСОВМЕСТИМО.

    ельзя расчитывать на то, что у сообщения в базе (Jam, Squish) есть какой-то перманентный абсолютный номер.

    Дану? В Сквише есть этот самый UMSGID (Unique Message Identifier).
    В Джаме есть номер сообщения в заголовках, но за константное время туда можно также добраться через BaseMsgNum прям.

    апример, хаски под низом использует smapi библиотеку, и там постоянные вызовы MsgMsgnToUid и MsgUidToMsgn, не знаешь зачем?

    В теории, можно написать пуржилку, которая будет сохранять номера
    писем, оставляя дырки в индексе, но такая пуржилка никому, кроме держателей странного софта, не нужна, поэтому вряд ли кто-то будет это делать.

    А знаешь сколько у разных утилит есть опций? апример, rsync, скопировать слева на право, казалось бы, а man rsync ты зачитаешься. Я про то, что кто как хочет, так и пуржит, только дайте опции людям. Людям, с потребностями разными. А которые без потребностей, тем и дефолт софйдёт какой-нибудь.

    После пуржинья, например, BaseMsgNum выставился в 5
    После пуржинга он должен выставиться в 1 и больше никогда не меняться вообще.

    у окей, в мире котором ты живёшь, там BaseMsgNum==1 всегда. Есть вариант, когда он не 1?
    Если ты начинаешь новую базу, то он 1, если продолжаешь старую, то уже не 1.

    Пойдём от обратного. Если BaseMsgNum есть, и учавствует в арифметике номеров сообщений, значит оно кому-то надо. Иначе бы такое поле не делали.

    В спеке он есть. ормальный софт всегда высчитывает номер
    сообщения прибавляя BaseMsgNum.

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

    Как минимум ты не понимешь юзкейс, почему BaseMsgNum может быть не 1.

    В спеке указан только один юзкейс для этого - удалить первые N
    сообщений в базе, точнее, сделать их "недоступными". Это явно было придумано до того, как сделали 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)
  • From Alexey Fayans@2:5030/1997 to Nil A on Fri Aug 25 09:15:16 2023
    Hello Nil!

    On Fri, 25 Aug 2023 at 07:25 +0300, you wrote to me:

    Такой софт должен импортировать сообщения в свою базу,
    предназначенную для таких специфичных действий.
    А вот и нет. Мне, лично, не симпатизируют все те разрабы, что
    засовывают сообщения в SQL, например. Засунули, свои какие-то там дела порешали, и всё, больше ни с кем не совместимо - пример тому JNode.

    Значит ты любитель костылестроения.

    А тут, мы берём, чиста по спекам, и всё работает, и со всеми
    совместимы. Только не все спеки читают, и пуржиют, как им в голову взбредёт.

    Изначально речь шла о сортировке, а не о пуржинге, и как ты себе представляешь сортировку без смены номера сообщения?

    Да и спеки никто не нарушает делая renumbering даже без сортировки. При упаковке это нормальная история. А вот оставлять дыры в индексе ради сохраниения номеров сообщений - это костыли, нужные только для работы специфичного софта, который вместо того, чтобы использовать нормальную БД, пытается работать с не предназначенной для таких целей JAM-базой.

    Либо строить какой-то свой индекс,
    Ага, типа как ластрид файлик, который опциональный, но про него хоть
    знают все, и его обновляют (иногда). Так то я и full-text search
    индекс могу положить рядом, чтобы поиск работал сразу, но это всё ЕСОВМЕСТИМО.

    Это и не должно быть совместимо, потому что нужно только одной специфичной софтине. И класть это нужно рядом с этой софтиной, а не с JAM-базой.

    ельзя расчитывать на то, что у сообщения в базе (Jam, Squish)
    есть какой-то перманентный абсолютный номер.
    Дану? В Сквише есть этот самый UMSGID (Unique Message Identifier).

    Это не номер сообщения в общепринятом понятии. В JAM прямо в заголовке есть MSGID, OADDRESS и DADDRESS, этого вполне достаточно для использования в качестве уникальной сигнатуры.

    В Джаме есть номер сообщения в заголовках, но за константное время
    туда можно также добраться через BaseMsgNum прям.

    Если быть точным, то BaseMsgNum нужен только для того, чтобы посчитать относительный номер сообщения, зная абсолютный, чтобы через JDX найти позицию заголовка в JHR и сделать туда fseek().

    Я ещё раз хочу подчеркнуть, что BaseMsgNum в разговоре о том, что пуржинг (точнее упаковка) может привести к изменению абсолютных номеров сообщений, не играет вообще никакой роли. Это всего лишь часть механики по вычислению относительного номера, зная абсолютный, и наоборот.

    апример, хаски под низом использует smapi библиотеку, и там
    постоянные вызовы MsgMsgnToUid и MsgUidToMsgn, не знаешь зачем?

    Я с этой либой не знаком, поэтому ХЗ.

    В теории, можно написать пуржилку, которая будет сохранять номера
    писем, оставляя дырки в индексе, но такая пуржилка никому, кроме
    держателей странного софта, не нужна, поэтому вряд ли кто-то
    будет это делать.
    А знаешь сколько у разных утилит есть опций?

    Для опций нужен код. Этот код кто-то должен написать. Я к тому, что никто такой код писать не будет, потому что нафиг это не нужено. Ибо <тут известная цитата про бедуинов>.

    После пуржинья, например, BaseMsgNum выставился в 5
    После пуржинга он должен выставиться в 1 и больше никогда не
    меняться вообще.
    у окей, в мире котором ты живёшь, там BaseMsgNum==1 всегда. Есть
    вариант, когда он не 1? Если ты начинаешь новую базу, то он 1, если продолжаешь старую, то уже не 1.

    ужно один раз делать упаковку такой старой базы, чтобы BaseMsgNum стал 1 и больше никогда не менялся. Поменяются абсолютные номера сообщений, зато относительные сохранятся (если не было удалений или сортировки).

    Пойдём от обратного. Если BaseMsgNum есть, и учавствует в арифметике номеров сообщений, значит оно кому-то надо.

    Ты как будто бы вообще не читаешь, что я пишу. е вижу смысла писать по кругу одно и то же.

    Иначе бы такое поле не делали.

    Его сделали когда-то давно, и его единственная задача - скрыть N сообщений с начала базы. апример, чтобы поддерживать фиксированное максимальное количество сообщений в базе без упаковки и пуржинга. Всё. Если у тебя в какой-то базе BaseMsgNum не 1, значит когда-то давно у тебя был настроен лимит сообщений. Если он у тебя всё ещё настроен, то регулярное изменение BaseMsgNum оправдано. Если нет, то нужно упаковать базу и забыть об этом.

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

    Я понимаю, а ты точно понимаешь?


    ... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
    --- GoldED+/W32-MSVC 1.1.5-b20230214
    * Origin: Music Station | https://ms.bsrealm.net (2:5030/1997)
  • From Nil A@2:5015/46 to Alexey Fayans on Fri Aug 25 17:28:44 2023
    Hello, Alexey!

    Friday August 25 2023 09:15, from Alexey Fayans -> Nil A:

    А вот и нет. Мне, лично, не симпатизируют все те разрабы, что
    засовывают сообщения в SQL, например. Засунули, свои какие-то там
    дела порешали, и всё, больше ни с кем не совместимо - пример тому
    JNode.
    Значит ты любитель костылестроения.

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

    Изначально речь шла о сортировке, а не о пуржинге, и как ты себе представляешь сортировку без смены номера сообщения?

    А вот, кстати, проблема тоже. Зачем мне каким-то образом сортировать сообщения в базе, т.е. как они там физически последовательно записаны в файле? Меня устраивает физический порядок следования записей, как они туда попадала - это же база просто.
    Ааа.. наверное почтовая программа не умеет сортировать так, как мне хотелось бы, а только последовательно из файла базы показывает сообщения, поэтому физческий порядок следования важен? А если я тредами показываю, у меня там сортировка другая, а если я по имени автора, а если у меня скоринг и сортируется хитро? ет, мы будет сортировать сообщения только тем "кашерным" способом, что нам предложил Стас своим скриптом.

    Да и спеки никто не нарушает делая renumbering даже без сортировки.

    ет, не нарушает. Просто он создаёт _новую_ базу. А кто имеет какие-то "индексы" к старой базе, то он страдает.

    Если быть точным, то BaseMsgNum нужен только для того, чтобы посчитать относительный номер сообщения, зная абсолютный, чтобы через JDX найти позицию заголовка в JHR и сделать туда fseek().

    Верно. Можно прыгать на абсолютный номер сообщения за O(1), прям пользуясь спеком, из-коробки. А msdid+oadress+... связка, этож надо сначала построить индекс, хотя дуполовка так и делает.

    Я ещё раз хочу подчеркнуть, что BaseMsgNum в разговоре о том, что
    пуржинг (точнее упаковка) может привести к изменению абсолютных
    номеров сообщений, не играет вообще никакой роли. Это всего лишь часть механики по вычислению относительного номера, зная абсолютный, и
    наоборот.

    Верно. Механизм есть, и он должен работать. Вопрос. Откуда у тебя изначально берётся абсолютный номер сообщения, что тебе надо пересчитывать на относительный? Значит тебе абсолютный номер зачем-то таки нужен?

    апример, хаски под низом использует smapi библиотеку, и там
    постоянные вызовы MsgMsgnToUid и MsgUidToMsgn, не знаешь зачем?
    Я с этой либой не знаком, поэтому ХЗ.

    у окей, не пользуешься 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)

    Как минимум ты не понимешь юзкейс, почему BaseMsgNum может быть
    не 1.
    Я понимаю, а ты точно понимаешь?

    А я вопросом на вопрос ;-) Зачем тебе может потребоваться абсолютный номер? Читай сообщения всю дорогу по относительному номеру, просто как смещение в файле.

    Best Regards, Nil
    --- GoldED+/LNX 1.1.5
    * Origin: Linux 2.6.32-042stab145.3 (2:5015/46)