Как минус - только чётные секунды могут хранится, а это уже означает, что дата оригинального сообщения искажена. Хотя, для этого есть оригинальное поле __ftsc_date на 20 байт, его можно сново распарсить и достать, но, например, хаски SMAPI библиотека так не делает. Тут в эхе fidosoft.husky, Oli 2:280/464 опять на эту тему распинался, что надо бы __ftsc_date парсить каждый раз в SMAPI.
VA>>> Какие еще плюсы Squish по сравнению с Jam?
Текущая реализация пуржилки в хаски sqpack, она ломает уникальность сообщений в Jam, если это кому-то важно, например jamnntpd/smapinntpd. Squish хранит связные списки, и там есть понятие Unique message ID ("USMGID"). Удаление сообщений в середине где-то не является большой проблемой, если это какой-то частый у тебя случай использования. В Jam так тоже можно сделать типа USMGID, просто прибавить basemsgnum к текущему номеру сообзения, но тогда надо оставлять "дырки", что немного расход байтиков, плюс sqpack эти дырки схлопывает и USMGID уже не рассчитаешь.
AS>> Hа один файл меньше для эхи (там только текст, индекс и lastread)
В JAM многие клюджи уже хранятся под ID, наверное так место меньше занимает, и может быть так быстрее искать кому-то. А ещё различие lastread в том, что в Squish есть понятие номера пользователя (в голдеде это называется SQUISHUSERNO), как и в Msg/Opus, а в JAM там CRC от юзернейма (UserID как-то не принято смотреть). Ещё в JAM есть отдельно последнее прочитанной сообщений, и последнее увиденное, но этим тоже никто не пользуется. Голдед, например, у себя сбоку хранит увиденные и последние, чтобы сказать сколько новых с последнего захода.
VA> Почему там нет проблемы 2038 года? :)
Как мы уже выяснили, проблемы 2038 года нет ни в Jam, ни в Squish, ни в Msg/Opus, в том месте, как хранится дата. А вот старый софт может не совсем корректно дату вычитывать и показывать, внутри себя оперируя с 32битным знаковым числом.
VA> А еще я слышал, что в Squish каждое письмо может быть прилинковано VA> максимум к 10 другим.
Там вшито replies word[9].
VA> А я использую линковку. В Jam нет такого ограничения.
Вообще, эта вся линковка, наверное требовалось в ДОСовские времена, когда дискеты или харды были медленными и памяти мало, и надо было прям оптимизированно бегать по индексам точно. Но сегодня почти весь софт себе целиком в память затаскивает весь индекс файл, и прям пробежаться и построить дерево ответов по тексту не сильно много времени займёт, каждый раз прям.
Best Regards, Nil --- GoldED+/LNX 1.1.5 * Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
