= Сообщение: 341 из 2735 ==================================== RU.FTN.DEVELOP = От : Mithgol the Webmaster 2:5063/88 06 Apr 14 11:51:52 Кому : All 06 Apr 14 11:51:52 Тема : О втором важном недостатке формата баз Squish по сравнению с JAM FGHI : area://RU.FTN.DEVELOP?msgid=2:5063/88+534107af = Кодировка сообщения определена как: CP866 ================================== ==============================================================================
Я не первый год говорю о том, что Squish как формат баз фидопочты обладает важным недостатком по сравнению с JAM: сквишёвая структура XMSG содержит только девять ссылок на отклики, поэтому, едва обсуждение некоторого сообщения в Фидонете становится более оживлённым, дерево сообщений начинает распадаться: эхопроцессор (тоссер) не может в полной мере сохранить дерево в базе Squish, фидобраузер вынужден самостоятельно сканировать заголовки всей эхи заново, разыскивая отклики. В то же время JAM хранит список откликов не в виде массива конечной длины, а в виде однонаправленного связанного списка (в полях Reply1st и ReplyNext), так что способен сохранять скль угодно ветвистые деревья.
Сегодня я хочу упомянуть второй важный недостаток Squish: по сравнению с JAM заголовок в базе Squish содержит меньше данных о сообщении. Иными словами, сквишёвая структура XMSG имеет фиксированную длину и не хранит никаких кладжей, тогда как в JAM структура MessageHeader имеет хвост переменной длины (подполя SubFieldXX) и хранит все кладжи сообщения. Это имеет тот эффект, что из XMSG можно узнать, как сообщение было озаглавлено (subject), но нельзя узнать его кодировку ── а значит, такое заглавие нельзя, в общем-то, выводить читателю до тех пор, пока не прочитано само сообщение и не найден кладж CHRS в нём. (Объём считываемых и обрабатываемых данных заметно возрастает в сравнении с JAM, где все необходимые данные лежат в заголовке.) Другой пример: utc_ofs упоминается в описании XMSG как не используемое поле, поэтому фидобраузер не может знать, в каком часовом поясе находится указанное в заголовке время.
Сразу скажу, впрочем, что этот недостаток несколько умаляется в силу того, что в заголовке SQHDR в поле ctrl_len указана длина контрольной информации, то есть (как о том по адресу area://FTSC_PUBLIC?msgid=2:5080/102.1+4b965140 или в WWW по адресу http://ftn.su/m/FTSC_PUBLIC/2:5080/102.1+4b965140 рассказано) длина кладжей в начале сообщения. Таким образом, фидобраузеру всё же не приходится считывать всё сообщение из базы, а достаточно прочесть только кладжи перед тем, как анализировать их. Однако задача расчленения контрольной информации на ряд отдельных кладжей и их первоначального анализа ── задача, которую для JAM может выполнить эхопроцессор (тоссер) ── в случае с Squish возложена на фидобраузер.
Вот пример: для фидобраузера полезною является задача поиска сообщений по их MSGID. Для JAM достаточно найти среди подполей то, которое имеет тип 'MSGID' (LoID равен 4, HiID равен 0) и прочесть из него MSGID. Чтобы найти, достаточно двух числовых сравнений (а чтобы отбраковать подполе как не содержащее MSGID, достаточным может быть и одно сравнение LoID без HiID). Для Squish же придётся проводить строковое сравнение в начале каждого кладжа и не раньше остановиться, чем все шесть символов 'MSGID:' совпадут. И такая разница между JAM и Squish в каждом сообщении ── а сообщений-то в эхе могут быть тысячи и десятки тысяч.
* изначально написано в эхоконференцию Ru.Fidonet.Today * также было отослано в эхоконференцию Ru.FTN.Develop
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... Мне больше всего хотелось, чтобы от меня отстали с дедушкой. (Е. Гайдар) --- Знаешь ли ты, что "Тёрнер" пишется через "ё"? * Origin: Геленджик лежит на юге Раши, где в лесу рыдают хигураши (2:5063/88)
