Фидонет окончательно умрёт в 2038ом?

Vitaliy Aksyonov написал(а) к Nil A в Feb 23 12:32:34 по местному времени:

Привет, Nil!

13 Feb 23 21:32, ты писал(а) мне:

VA>>>> В Squish поля даты как-то иначе реализованы?
NA> В Squish используется формат даты DOS 32-битовые поля
NA> https://learn.microsoft.com/en-us/cp...32-bit-windows
NA> -time-date-formats

NA> Как минус - только чётные секунды могут хранится, а это уже означает,
NA> что дата оригинального сообщения искажена. Хотя, для этого есть
NA> оригинальное поле _ftscdate на 20 байт, его можно сново распарсить и
NA> достать, но, например, хаски SMAPI библиотека так не делает. Тут в эхе
NA> fidosoft.husky, Oli 2:280/464 опять на эту тему распинался, что надо
NA> бы _ftscdate парсить каждый раз в SMAPI.

Это не такая большая проблема. Я не думаю, что кто-то сильно заморачивается точностью в секунды. :) А кому надо - пусть присылает патч (с). :D

VA>>>> Какие еще плюсы Squish по сравнению с Jam?

NA> Текущая реализация пуржилки в хаски sqpack, она ломает уникальность
NA> сообщений в Jam, если это кому-то важно, например jamnntpd/smapinntpd.
NA> Squish хранит связные списки, и там есть понятие Unique message ID
NA> ("USMGID"). Удаление сообщений в середине где-то не является большой
NA> проблемой, если это какой-то частый у тебя случай использования. В Jam
NA> так тоже можно сделать типа USMGID, просто прибавить basemsgnum к
NA> текущему номеру сообзения, но тогда надо оставлять "дырки", что
NA> немного расход байтиков, плюс sqpack эти дырки схлопывает и USMGID уже
NA> не рассчитаешь.

Погоди. В JAM есть MSGID. Никто не мешает софту вычитывать MSGID, а не использовать номер сообщения в базе.

AS>>> На один файл меньше для эхи (там только текст, индекс и
AS>>> lastread)

NA> В JAM многие клюджи уже хранятся под ID, наверное так место меньше
NA> занимает, и может быть так быстрее искать кому-то. А ещё различие
NA> lastread в том, что в Squish есть понятие номера пользователя (в
NA> голдеде это называется SQUISНUSERNO), как и в Msg/Opus, а в JAM там
NA> CRC от юзернейма (UserID как-то не принято смотреть). Ещё в JAM есть
NA> отдельно последнее прочитанной сообщений, и последнее увиденное, но
NA> этим тоже никто не пользуется. Голдед, например, у себя сбоку хранит
NA> увиденные и последние, чтобы сказать сколько новых с последнего
NA> захода.

Я с Jam форматом разбирался когда-то. Даже наваял либу небольшую на Java, которая читает этот формат. Правда, на запись меня не хватило. :D

VA>> Почему там нет проблемы 2038 года? :)

NA> Как мы уже выяснили, проблемы 2038 года нет ни в Jam, ни в Squish, ни
NA> в Msg/Opus, в том месте, как хранится дата. А вот старый софт может не
NA> совсем корректно дату вычитывать и показывать, внутри себя оперируя с
NA> 32битным знаковым числом.

Ну и слава яйцам. А кто пользуется старым софтом - ССЗБ. Ну или пропатчат.

VA>> А еще я слышал, что в Squish каждое письмо может быть
VA>> прилинковано максимум к 10 другим.
NA> Там вшито replies word[9].

Вот-вот. Даже 9, а не 10.

VA>> А я использую линковку. В Jam нет такого ограничения.
NA> Вообще, эта вся линковка, наверное требовалось в ДОСовские времена,
NA> когда дискеты или харды были медленными и памяти мало, и надо было
NA> прям оптимизированно бегать по индексам точно. Но сегодня почти весь
NA> софт себе целиком в память затаскивает весь индекс файл, и прям
NA> пробежаться и построить дерево ответов по тексту не сильно много
NA> времени займёт, каждый раз прям.

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

Best regards,
Vitaliy Aksyonov.

... Нет ничего быстрее мысли. Нет ничего медленее думы.
--- GoldED+/LNX 1.1.5-b20230205