MtW>> 3) Растровые иллюстрации (PNG, JPEG, GIF) и векторные иллюстрации MtW>> (SVG) автоматически декодируются из UUE и показываются на месте MtW>> UUE-кодов.
VF> Лучше бы картинки (а также видео и музыка) подгружались из инета по VF> ссылкам, как в хотдоге или wFido.
Во-первых, одно другому не мешает. Если в письме есть UUE-коды, то их неплохо б показывать вне всякой зависимости от того, как приложение поступает с другими элементами письма (с URLами, например); и показываю.
Во-вторых, мне на самом деле не очень нравится идея о том, что каждый адрес некоторой картинки, просто появившись в письме, вызывает скачивание картинки из Сети Интернет. Этим мы отрицаем десятилетия интернетовской традиции, а ведь в ней есть разумные элементы. Так, например, в Интернете можно дать адрес картинки, крупной по объёму, и рядом текстом предупредить, что скачивать её (переходить по этому адресу) надо только в случае достаточно быстрого Интернета и без оплаты за траффик. Если же в Фидонете будет HotdogEd у кого-нибудь качать автоматически по мобильному Интернету, то может получиться или медленно, или с оплатою за траффик, или и то, и другое вместе случится; пользователь такому не порадуется.
Следует вместо этого завести какую-нибудь простую разметку (проще, чем HTML), которая позволяла бы:
1) указать, что адрес следует отображать как картинку;
2) указать альтернативный текст на случай нескачиваемости картинки (ну или на случай текстового неграфического просмотрщика);
3) дополнительно (не обязательно) указать подсказку, которая в системах с мышью будет всплывать при наведении мыши на картинку, а в системах без мыши будет всплывать при долгом нажатии пальцем на картинку.
Для этой цели предлагаю ту разметку, которая в языке Markdown используется для разметки картинок: восклицательный знак, затем в квадратных скобках идёт альтернативный текст, затем в круглых скобках идёт URL (и после него может до закрывающей круглой скобки идти отделённая от него пробелом подсказка, заключённая в кавычки). Вот реализация в моём модуле на языке JavaScript для движка Node.js:
MtW>> 4) Поддержка фидонетовских подстрок Unicode.
VF> Боюсь спросить, что это такое.
Мой робот раз в месяц публикует в этой эхоконференции письмо под заголовком 'Черновик стандарта фидонетовских подстрок Unicode (русская версия)'. И в нём сообщается, что это такое.
MtW>> 5) В заголовке сообщения отображается аватар (юзерпик) автора MtW>> сообщения.
VF> Откуда берётся? Из кладжа GIF?
Мой робот раз в месяц публикует в этой эхоконференции письмо под заголовком 'Черновик стандарта фидонетовских аватар (русская версия)'. И в нём сообщается, откуда берётся.
Боюсь спросить: неужели ежемесячное оповещение фидонетовского сообщества о направлении моих разработок оказалось совершенно не действенным?
MtW>> Сразу скажу, что пока поддерживаются только базы в формате JAM,
VF> И вот он, полный облом. У меня Squish.
Я никак не могу вспомнить, задавал тебе вопрос о том, почему Squish (а не JAM), или не задавал, а если задавал, то что ты ответил. В пользу JAM и против Squish есть тот аргумент, что у Squish в заголовке сообщения предусмотрено довольно ограниченное место для хранения ссылок на отклики на сообщение, там всего 9 таких ссылок. Соответственно, если в Фидонете на некоторое сообщение поступит более девяти откликов, то дерево откликов либо не будет целиком построено (если автор программы не предусмотрел этот случай), либо будет строиться очень долго (если автор запустил перебор всех последующих сообщений). В формате же JAM отклики представляют собою связанный список, не имея собственного ограничения по количеству откликов. Есть ли равный по силе аргумент в пользу формата Squish и в пользу формата JAM?
Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/ Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]
... Dimensional Door Spell ── ваш приём против лома! --- Ты знал, но играл с огнём и попался в Сеть! Hо я не враг твой, я твой друг * Origin: И тогда советские ── по пояс в снегу ── двинулись вперёд! (2:50/88)
