= Сообщение: 32349 из 47643 =============================== RU.FIDONET.TODAY =
От : Vitaliy Aksyonov 1:104/117 13 Feb 23 12:32:34
Кому : Nil A 13 Feb 23 12:32:34
Тема : Re: Фидонет окончательно умрёт в 2038ом?
FGHI : area://RU.FIDONET.TODAY?msgid=1:104/117+63ea913c
На : area://RU.FIDONET.TODAY?msgid=2:5015/46+63ea8c9b
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FIDONET.TODAY?msgid=2:5015/46+63ea9359
==============================================================================
Привет, Nil!
13 Feb 23 21:32, ты писал(а) мне:
VA>>>> В Squish поля даты как-то иначе реализованы?
NA> В Squish используется формат даты DOS 32-битовые поля
NA> https://learn.microsoft.com/en-us/cpp/c-runtime-library/32-bit-windows
NA> -time-date-formats
NA> Как минус - только чётные секунды могут хранится, а это уже означает,
NA> что дата оригинального сообщения искажена. Хотя, для этого есть
NA> оригинальное поле __ftsc_date на 20 байт, его можно сново распарсить и
NA> достать, но, например, хаски SMAPI библиотека так не делает. Тут в эхе
NA> fidosoft.husky, Oli 2:280/464 опять на эту тему распинался, что надо
NA> бы __ftsc_date парсить каждый раз в 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>>> Hа один файл меньше для эхи (там только текст, индекс и
AS>>> lastread)
NA> В JAM многие клюджи уже хранятся под ID, наверное так место меньше
NA> занимает, и может быть так быстрее искать кому-то. А ещё различие
NA> lastread в том, что в Squish есть понятие номера пользователя (в
NA> голдеде это называется SQUISHUSERNO), как и в 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
* Origin: Aurora, Colorado (1:104/117)
|
