Притензия в том, что создаётся новый файл с базой, в которомЭто проблемы кривого софта типа SmapiNNTPd, а не пуржилки.
нумерация $BaseMsgNum начнётся заново, а это значит всякие
ништяки, типа SmapiNNTPd поломаются, потому что не смогут сразу
прыгнуть на нужный номер, потому что базовый номер съехал.
Упаковать JAM базу без сброса BaseMsgNum, наверное, возможно, но это крайне тупо.
Вообще, BaseMsgNum - это рудимент, нормальный софт его не трогает.
Это проблемы кривого софта типа SmapiNNTPd, а не пуржилки.
Пример, надо тебе написать софт, который сразу может прыгать на
10ое сообщение из JAM базы. После пуржинья, предположим, это
сообщение стало 5ым. Линеный поиск сообщения по всей базе не
предлагать O(n).
Такой софт должен импортировать сообщения в свою базу, предназначенную
для таких специфичных действий.
Либо строить какой-то свой индекс,
ельзя расчитывать на то, что у сообщения в базе (Jam, Squish) есть какой-то перманентный абсолютный номер.
В теории, можно написать пуржилку, которая будет сохранять номера
писем, оставляя дырки в индексе, но такая пуржилка никому, кроме держателей странного софта, не нужна, поэтому вряд ли кто-то будет это делать.
После пуржинья, например, BaseMsgNum выставился в 5После пуржинга он должен выставиться в 1 и больше никогда не меняться вообще.
В спеке он есть. ормальный софт всегда высчитывает номер
сообщения прибавляя BaseMsgNum.
Всё верно, потому что если какой-то древний софт зачем-то меняет BaseMsgNum, то любой другой софт должен это учитывать. о при пуржинге
(а точнее при упаковке) оставлять BaseMsgNum отличным от 1 - как
минимум странно.
В спеке указан только один юзкейс для этого - удалить первые N
сообщений в базе, точнее, сделать их "недоступными". Это явно было придумано до того, как сделали soft delete. Сейчас в этом смысла нет.
Такой софт должен импортировать сообщения в свою базу,А вот и нет. Мне, лично, не симпатизируют все те разрабы, что
предназначенную для таких специфичных действий.
засовывают сообщения в SQL, например. Засунули, свои какие-то там дела порешали, и всё, больше ни с кем не совместимо - пример тому JNode.
А тут, мы берём, чиста по спекам, и всё работает, и со всеми
совместимы. Только не все спеки читают, и пуржиют, как им в голову взбредёт.
Либо строить какой-то свой индекс,Ага, типа как ластрид файлик, который опциональный, но про него хоть
знают все, и его обновляют (иногда). Так то я и full-text search
индекс могу положить рядом, чтобы поиск работал сразу, но это всё ЕСОВМЕСТИМО.
ельзя расчитывать на то, что у сообщения в базе (Jam, Squish)Дану? В Сквише есть этот самый UMSGID (Unique Message Identifier).
есть какой-то перманентный абсолютный номер.
В Джаме есть номер сообщения в заголовках, но за константное время
туда можно также добраться через BaseMsgNum прям.
апример, хаски под низом использует smapi библиотеку, и там
постоянные вызовы MsgMsgnToUid и MsgUidToMsgn, не знаешь зачем?
В теории, можно написать пуржилку, которая будет сохранять номераА знаешь сколько у разных утилит есть опций?
писем, оставляя дырки в индексе, но такая пуржилка никому, кроме
держателей странного софта, не нужна, поэтому вряд ли кто-то
будет это делать.
После пуржинья, например, BaseMsgNum выставился в 5
После пуржинга он должен выставиться в 1 и больше никогда неу окей, в мире котором ты живёшь, там BaseMsgNum==1 всегда. Есть
меняться вообще.
вариант, когда он не 1? Если ты начинаешь новую базу, то он 1, если продолжаешь старую, то уже не 1.
Пойдём от обратного. Если BaseMsgNum есть, и учавствует в арифметике номеров сообщений, значит оно кому-то надо.
Иначе бы такое поле не делали.
Всё верно, потому что если какой-то древний софт зачем-то меняетКак минимум ты не понимешь юзкейс, почему BaseMsgNum может быть не 1.
BaseMsgNum, то любой другой софт должен это учитывать. о при
пуржинге (а точнее при упаковке) оставлять BaseMsgNum отличным от
1 - как минимум странно.
А вот и нет. Мне, лично, не симпатизируют все те разрабы, чтоЗначит ты любитель костылестроения.
засовывают сообщения в SQL, например. Засунули, свои какие-то там
дела порешали, и всё, больше ни с кем не совместимо - пример тому
JNode.
Изначально речь шла о сортировке, а не о пуржинге, и как ты себе представляешь сортировку без смены номера сообщения?
Да и спеки никто не нарушает делая renumbering даже без сортировки.
Если быть точным, то BaseMsgNum нужен только для того, чтобы посчитать относительный номер сообщения, зная абсолютный, чтобы через JDX найти позицию заголовка в JHR и сделать туда fseek().
Я ещё раз хочу подчеркнуть, что BaseMsgNum в разговоре о том, что
пуржинг (точнее упаковка) может привести к изменению абсолютных
номеров сообщений, не играет вообще никакой роли. Это всего лишь часть механики по вычислению относительного номера, зная абсолютный, и
наоборот.
апример, хаски под низом использует smapi библиотеку, и тамЯ с этой либой не знаком, поэтому ХЗ.
постоянные вызовы MsgMsgnToUid и MsgUidToMsgn, не знаешь зачем?
Как минимум ты не понимешь юзкейс, почему BaseMsgNum может бытьЯ понимаю, а ты точно понимаешь?
не 1.
Sysop: | Angel Ripoll |
---|---|
Location: | Madrid, Spain |
Users: | 21 |
Nodes: | 8 (0 / 8) |
Uptime: | 196:59:49 |
Calls: | 60 |
Calls today: | 1 |
Files: | 2,677 |
Messages: | 42,543 |