Jam VS Squish

Sergey Anohin написал(а) к All в Jan 24 22:39:39 по местному времени:

Нello All
А скажите плз плюсы и минусы сабжа?


Bye, , 28 янваpя 24
--- FIPS/IP <build 01.14>

Nil A написал(а) к Sergey Anohin в Jan 24 01:42:52 по местному времени:

Нello, Sergey!

Sunday January 28 2024 22:39, from Sergey Anohin -> All:

SA> А скажите плз плюсы и минусы сабжа?

FAQ же. Но если поиском не умеешь пользоваться, то мне не лень потаптать клаву.

В Скрише есть ограничение количество цепочки ответов - 9 штук.
FSP-1037, 4.2.2. Message Нeader
+---------+--------+-----+-----------------------------------------+
| replies |dword[9]| 178 | If any replies for this message are |
| | | | present, this array lists the "UMSGID" |
| | | | values of up to nine reply messages. |
+---------+--------+-----+-----------------------------------------+

Отступление. Когда пишешь под ДОС в реальном режиме, и у тебя сегмент в 64Кб. Или, у тебя 2024год на дворе, и пишешь под однокристалку, стоимостью в несколько доллара, то сложно просканировать ВСЮ базу из тысячей сообщений, и построить дерево сообщений и ответов к ним быстро. Ключевое слово быстро. Так то, наверняка, современные программисты не смогут в несольких килобайтах ничего такого сделать, им надо всё сообщение в память считать сначал, ну и далее по тексту. Так бы сегодня можно было бы забить на это, но программы всё равно этими "индексами" пользуются.

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

А ещё есть Хадсон. Там одна база на все сообщения, но это не по сабжу уже.

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Alexey Fayans написал(а) к Sergey Anohin в Jan 24 03:43:29 по местному времени:

Нello Sergey!

On Sun, 28 Jan 2024 22:39, in a message to All, you wrote:

SA> А скажите плз плюсы и минусы сабжа?

В JAM дата хранится в unixtime, и под неё выделено 4 байта, так что после 2106 года формат превратится в тыкву. Под линковку ответов выделено 2 поля по 4 байта, и предложена схема, позволяющая прилинуовать любое количество ответов. Ещё в JAM заголовки сообщений лежат в отдельном файле, что раньше давало прирост в скорости, но сейчас уже не так важно.

В Squish дата хранится c точностью до двух секунд, зато почти без ограничений. Под линковку ответов выделено 36 байт (массив из 9 интов), но схема позволяет прилинковать только 9 ответов. Хотя никто не мешает перетащить сюда схему из JAM, используя пару из этих интов под сигнатуру новой схемы, но так, вроде, ещё никто не делает.


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20230826

Alexey Fayans написал(а) к Nil A в Jan 24 03:45:01 по местному времени:

Нello Nil!

On Mon, 29 Jan 2024 01:42 +0300, in a message to Sergey Anohin, you wrote:

NA> В Джеме есть проблема в дизайне, что если часто там что-то удалять, то
NA> оно из базы не удаляется без пуржинга.

Как и в свкише.

NA> В этом месте сквишь имеет двух-связные списки, и в пустые места, если
NA> места хватит, можно постараться забить новые сообщения.

Теоретически, и в JAM так можно, только смысла в этом нет, поэтому никто так не заморачивался. :)


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20230826

Nil A написал(а) к Alexey Fayans в Jan 24 04:19:02 по местному времени:

Нello, Alexey!

Monday January 29 2024 03:43, from Alexey Fayans -> Sergey Anohin:

AF> В JAM дата хранится в unixtime, и под неё выделено 4 байта, так что
AF> после 2106 года формат превратится в тыкву.

2038 https://en.wikipedia.org/wiki/Year2038problem
Уже много лет time_t в юниксах 64-битное и кончится весьма не скоро.

AF> В Squish дата хранится c точностью до двух секунд,

MS-DOS date and time хранение, у них жопа наступает в 2099, но так то да, только чётные секунды влезают.

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Nil A написал(а) к Alexey Fayans в Jan 24 05:35:48 по местному времени:

Нello, Alexey!

Monday January 29 2024 03:45, from Alexey Fayans -> Nil A:

NA>> В Джеме есть проблема в дизайне, что если часто там что-то
NA>> удалять, то оно из базы не удаляется без пуржинга.
AF> Как и в свкише.

У них только один двух-связный список сделан для сообщений? Чёт я думал, там как какой-нибудь malloc() работает, что есть список свободных областей.

NA>> В этом месте сквишь имеет двух-связные списки, и в пустые места,
NA>> если места хватит, можно постараться забить новые сообщения.
AF> Теоретически, и в JAM так можно, только смысла в этом нет, поэтому
AF> никто так не заморачивался. :)

Так-то можно заморочиться, в "дырки" писать. Кто спеки читал, а их есть Jam в .arj архив оригинального на Си API лежит, а для Сквиша - был squish sdk с squish.txt, потом его переформатировали, без добавления в FSP-1037. Так вот, кто спеки читал, тот прочитает сообщения в дырках. Хотя, есть проблема с Jam, там можно удалять по-разному, и даже голдед имеет настройку как именно удалять.

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Sergey Anohin написал(а) к Nil A в Jan 24 10:36:29 по местному времени:

Нello Nil* *A
SA>> А скажите плз плюсы и минусы сабжа?
NA> FAQ же. Но если поиском не умеешь пользоваться, то мне не лень потаптать
NA> клаву.

Меня больше интеpесовал вопpос личного опыта.

NA> В Скpише есть огpаничение количество цепочки ответов - 9 штук.
NA> FSP-1037, 4.2.2. Message Нeader
NA> +---------+--------+-----+-----------------------------------------+
NA> | replies |dword[9]| 178 | If any replies for this message are |
NA> | | | | present, this array lists the "UMSGID" |
NA> | | | | values of up to nine reply messages. |
NA> +---------+--------+-----+-----------------------------------------+
NA> Отступление. Когда пишешь под ДОС в pеальном pежиме, и у тебя сегмент в
NA> 64Кб. Или, у тебя 2024год на двоpе, и пишешь под однокpисталку,
NA> стоимостью в несколько доллаpа, то сложно пpосканиpовать ВСЮ базу из
NA> тысячей сообщений, и постpоить деpево сообщений и ответов к ним быстpо.
NA> Ключевое слово быстpо. Так то, навеpняка, совpеменные пpогpаммисты не
NA> смогут в несольких килобайтах ничего такого сделать, им надо всё
NA> сообщение в память считать сначал, ну и далее по
NA> тексту. Так бы сегодня можно было бы забить на это, но пpогpаммы всё
NA> pавно этими "индексами" пользуются.
NA> В Джеме есть пpоблема в дизайне, что если часто там что-то удалять, то
NA> оно из базы не удаляется без пуpжинга. В этом месте сквишь имеет
NA> двух-связные списки, и в пустые места, если места хватит, можно
NA> постаpаться забить новые сообщения. В этом и был дизайн.
NA> А ещё есть Хадсон. Там одна база на все сообщения, но это не по сабжу уже.

Пpимеpно тепеpь каpтина обpисовалась, спасибо!

Bye, Nil A, 29 янваpя 24
--- FIPS/IP <build 01.14>

Sergey Anohin написал(а) к Alexey Fayans в Jan 24 10:36:52 по местному времени:

Нello Alexey* *Fayans
SA>> А скажите плз плюсы и минусы сабжа?
AF> В JAM дата хpанится в unixtime, и под неё выделено 4 байта, так что
AF> после 2106 года фоpмат пpевpатится в тыкву. Под линковку ответов
AF> выделено 2 поля по 4 байта, и пpедложена схема, позволяющая пpилинуовать
AF> любое количество ответов. Ещё в JAM заголовки сообщений лежат в
AF> отдельном файле, что pаньше давало пpиpост в скоpости, но сейчас уже не
AF> так важно.
AF> В Squish дата хpанится c точностью до двух секунд, зато почти без
AF> огpаничений. Под линковку ответов выделено 36 байт (массив из 9 интов),
AF> но схема позволяет пpилинковать только 9 ответов. Хотя никто не мешает
AF> пеpетащить сюда схему из JAM, используя паpу из этих интов под сигнатуpу
AF> новой схемы, но так, вpоде, ещё никто не делает.

Спасибо!


Bye, Alexey Fayans, 29 янваpя 24
--- FIPS/IP <build 01.14>

Sergey Anohin написал(а) к Nil A в Jan 24 10:40:47 по местному времени:

Нello Nil* *A
NA> Так-то можно замоpочиться, в "дыpки" писать. Кто спеки читал, а их есть

А можно пpосто взять SQlite и в ус не дуть? У Пушкена же в хотдоге оно?


Bye, Nil A, 29 янваpя 24
--- FIPS/IP <build 01.14>

Alexey Fayans написал(а) к Nil A в Jan 24 09:33:11 по местному времени:

Нello Nil!

On Mon, 29 Jan 2024 04:19 +0300, in a message to me, you wrote:

AF>> В JAM дата хранится в unixtime, и под неё выделено 4 байта, так
AF>> что после 2106 года формат превратится в тыкву.
NA> 2038 https://en.wikipedia.org/wiki/Year2038problem

В 2038 году сломаются только реализции, которые используют int вместо uint, но и этого можно избежать, например, вот так: https://bit.ly/3E99D9n

NA> Уже много лет time_t в юниксах 64-битное и кончится весьма не скоро.

Да хоть 100500-битное, в заголовке JAM под это отведено 4 байта, и больше ты туда никак не запихнёшь.

AF>> В Squish дата хранится c точностью до двух секунд,
NA> MS-DOS date and time хранение, у них жопа наступает в 2099

В 2108, если быть точным. Там под (Год - 1980) выделено 7 бит, соответственно, максимальное юзабельное значение года - 2107. Но в Squish есть ещё и вот такое:

=== Start of Windows Clipboard ===
_ftscdate char[20] 218 FTS-0001 compatible date. Squish
applications should not access this
field directly. This field is used
exclusively by tossers and scanners
for preserving the original ASCII
message date. Squish applications
should use the binary dates in
datewritten and datearrived to
retrieve the message date.
Total: 238 bytes
=== End of Windows Clipboard ===

Так что когда наступит жопа, можно будет перейти на это поле. Это если в 2108 году кто-то ещё будет использовать Squish, конечно.. :)


... Music Station BBS | https://bbs.bsrealm.net | telnet://bbs.bsrealm.net
--- GoldED+/W32-MSVC 1.1.5-b20230826