prev
next
ru.ftn.develop
FromMithgol the Webmaster2:5063/88.0Date Write2008-06-19 16:59:27
ToDmitriy Romanov0:0/0.0Date Arrived2008-06-19 20:01:23
SubjОбсуждение отдельных решений, заложенных в FGHI URL
Attr
Так было 22:09 18 Jun 08 написано от Dmitriy Romanov к Mithgol the Webmaster:

DR>>> При ссылке на конкретное письмо эта часть обязательна. Все остальное,
DR>>> что может быть найдено по поиску - это уже необязательно. Без этого
DR>>> будет ссылка на эху. А заданый поиск - на некоторое подмножество писем
DR>>> в эхе. Только MSGID будет всегда указывать только на одно письмо.
MtW>> Нет, не только.
MtW>> Ссылка вида area://Ru.FTN.Develop/?time=2008/06/17T20:55:00 тоже
MtW>> указывает только на одно письмо.
DR> Hе на одно письмо, а на множество писем, написанных в это время.

Согласен. Однако в данном конкретном частном случае это множество содержит
одно-единственное письмо.

MtW>> Да и вообще, мало ли фильтров, позволяющих свести итоговое множество
MtW>> писем к такому, которое будет содержать только одно письмо?

DR> В том то и дело, что это множество. Даже из одного письма. А не письмо.

Разница, на которую ты указываешь ── терминологическая, а не фактическая.
Действия гипертекстового браузера Фидонета не будут качественно отличаться
в том случае, когда он имеет дело всегда с одним письмом, и в том случае, когда
он имеет дело со множеством, в котором может быть несколько писем, а сейчас
одно.

MtW>> Я имел в виду вот какое возражение: если у тебя кусок пути файла,
MtW>> начинающийся с msgid=, то он уж не может быть именем архива, например.
MtW>> Стало быть, появится неоднозначность, если у тебя есть имя архива,
MtW>> начинающееся на 'msgid', или если в будущем, кроме msgid, появятся ещё
MtW>> какие-нибудь однозначные идентификаторы писем.
DR> Hеа. Тут ты неправ. Имя архива начинается после указания письма. Архив не
DR> может лежать в эхе но при этом не в письме.

Да. Но всегда ли нам так важно, в каком письме лежит он, и притом настолько
важно, чтобы делать идентификатор письма обязательной частью адреса архива?

MtW>> Насколько я понимаю, ты это возражение снимаешь вот каким образом: ты
MtW>> желаешь, чтобы msgid был обязательной второй частью адреса файла
MtW>> (после эхи), и чтобы он был единственно возможным идентификатором
MtW>> письма.
DR> Ага.

А вот это совершенно лишнее.

MtW>> И то, и другое представляется мне, в свою очередь, неприемлемым
MtW>> ужесточением правил по сравнению с моим собственным черновиком этого
MtW>> стандарта, в котором сказано, что автор URLа какими угодно фильтрами
MtW>> задаёт множество сообщений (не обязательно состоящее только из одного
MtW>> сообщения; даже не обязательно состоящее из сообщений только одного
MtW>> автора) и объект (файл) в нём. Если в этом множестве отыскивается
MtW>> несколько писем с одноимёнными файлами, то берётся последний (наиболее
MtW>> недавний).
DR> Это уже не ссылка, а поисковый запрос.

А чем поиск по msgid принципиально отличается от поиска по времени
или по теме письма?

MtW>> Твоё ужесточение лишает URLы файлов Фидонета целого ряда полезных
MtW>> применений. Упомяну об одном из них на примере Всемирной Паутины.
MtW>> Картинка, по адресу http://informer.gismeteo.ru/37004-10.GIF лежащая,
MtW>> показывает погоду в моём городе. И она время от времени обновляется,
MtW>> чтобы всегда показывать погоду
MtW>> в моём городе. Может ли существовать аналогичный URL в Фидонете? Да.
MtW>> Если мы представим себе эхоконференцию Gismeteo.Weather.Gelendzhik, в
MtW>> которую пишет какой-нибудь WeatherBot с адреса 2:9999/9999.99,
MtW>> несколько раз в день кладя туды UUE-кодированную картинку weather.gif,
MtW>> то по моему стандарту у картинки есть адрес
MtW>> area://Gismeteo.Weather.Gelendzhik/weather.gif?from=2:9999/9999.99
MtW>> (который всё время указывает на наиновейшую её версию).
DR> Hеа. Тут я склонен все-таки примкнуть к скептикам (коих, согласись,
DR> большинство) и сказать то же, что и все - ФИДО ДЛЯ ЭТОГО HЕ
DR> ПРЕДHАЗHАЧЕHО!!! Hа крайняк это будет специальный софт, который будет
DR> отслеживать последнее письмо и выковыривать. Hо ради одного такого случая
DR> городить огород не стоит. Все-таки для обновляемой в реальном времени
DR> информации есть инет. Или фрек на худой конец.

Внимательно перечитай вышеприведённый пример. Я говорил не о реальном времени,
а о периодичности наподобие, скажем, четырёх раз в сутки. Что смущает тебя
в том, что в какой-то эхе будет утром и днём и вечером и ночью появляться
новая версия некоторого графического файла? Частота обновления тебя смущает?
Или графическое содержимое? Ну представь тогда, например, что тебе надо дать
ссылку на текст последней версии правил некоторой эхоконференции. Что может
быть естественнее, чем URL следующего вида:

area://Example.Echomail/rules.txt?sender=Moderator&from=2:345/678.9

Нужда такая ── нужда дать ссылку на текст последней версии правил эхи ── может
возникнуть, например, при составлении XML-эхолиста, или при создании некоторой
соответствующей специальной страницы форума-гейта (на которой пользователи его
могут по ссылкам ознакомиться с правилами эх). Такая нужда неизбежна.

Вот тебе пример ссылки на текст вместо картинки, на редко обновляемый текст
вместо часто обновляемой картинки. Но ключевая особенность осталась: ссылка
ведёт на самую последнюю версию объекта (файла).

Ты можешь ещё возразить мне на это, что rules.txt никто не станет упаковывать
в формате UUE, поскольку модератор желал бы видеть рулесы читаемыми. Но, желая
предупредить это возражение, я без промедления поведаю тебе (и другим читателям
эхи) о формате Сергея Коровкина, который позволяет и сохранить читаемость всего
текста, помещаемого в эху, и привести имя его файла, и (при необходимости)
разбить текст на части в одном или нескольких письмах. Формат этот существует
десять лет, с 1998 года.

─ Семиотика ──────────────────────────────────────────────────── RU.SEMIOTICS ─
От : Moderator 2:5020/2613.5 24 Oct 03 20:57:06
Кому : Maelor D. Las 29 Oct 03 23:16:53
Тема : Постинг больших текстов
───────────────────────────────────────────────────────────────────────────────
@REALNAME: Марина Александровна Разводовская-Алёхина
@GC: Phaino 2.0 _B*D-L+<STx* b011279 PC9343 Net452 netB-Ff-W~$< com2 msg2$<
@GC: OS3351 osDW>L hex4 Eg1 pub4 USA2 god1 hak45+ xsc4 UFO4< psyF/A/9 mus01
@GC: TV2 gam01 hum2 lab5 lov5 lib15 edu44 lng31>2 mth4 co1< petabcr;

· В этой эхоконференции тексты из нескольких частей следует
постить в специальном формате, описываемом ниже. Рекомендую осво-
ить и применять всегда.

Как правильно постить тексты в эхоконференции
(формат постинга текстов sergey korowkin)

(x) Copyleft, Marїnais, 01.05.2003


Если вы публикуете текст в эхоконференции, какое-то ко-
личество читателей может захотеть сохранить его у себя, но
не в виде сообщений в почтовой базе, а в виде нормального
текстового файла, каким он был до помещения его вами в эхо-
конференцию.
Когда текст небольшой, сделать это несложно. Hо по мере
увеличения его размеров, задача обрастает трудностями в гео-
метрической прогрессии. Мало сохранить все секции в файл ─
их надо ещё найти и состыковать в правильной последователь-
ности, поскольку приходят они часто перемешанными. Также ну-
жно удалить из них заголовки, элементы оформления и техниче-
ские строки. Дело осложняется тем, что у разных людей это
оформление совершенно разное, что сильно затрудняет какую-
либо автоматическую обработку. А теперь представьте, что вам
нужно так обработать целую книгу на несколько сотен кило-
байт, пришедшую к вам в виде нескольких сотен же перемешан-
ных секций, каждая из которых снабжена "бородой" из оформле-
ния. 8-) Понятно, что приведение её в исходный нормальный
вид ─ задача совсем не тривиальная. Сохранить же секции про-
сто одну за другой в файл ─ значит получить нелепого уродца,
в котором через каждые 3─4 экрана текст будет прерываться
неуместной порцией почтовой белиберды. Словом, тот, кто хоть
раз не только постил, но и пытался сам извлекать запощенное
кем-то другим, до "посинения" подбирая секции и вырезая в
редакторе технический мусор из получившегося, уже понял, о
чём идёт речь...
Если вы у в а ж а е т е тех, кто будет читать помеща-
емый вами текст и захочет превратить его в нормальный файл,
вы должны п о м о ч ь им в этом, снабдив текст технически-
ми строками в специальном формате. Тогда задачу по извлече-
нию текста из базы сообщений смогут взять на себя п р о г -
р а м м ы , и она из муки сведётся к нажатию пары кнопок.
Для корректной публикации текстов в эхоконференциях из-
вестный программист sergey korowkin разработал в 1998 г.
специальный формат, поддерживаемый, вчастности, программами
UUE Wizard и FastPost/FastUUE. Эти программы обеспечивают
как автоматическое извлечение пришедшего текста, так и пост-
инг его в эхоконференцию. При этом они полностью берут на
себя все функции по дроблению/сборке секций и их оформлению.
Однако, формат этот настолько прост, что даже не имея
упомянутых программ, вы с а м и можете привести в соответ-
ствие с ним отправляемые секции, добавив к каждой из них
всего по 3 строки.
Процедура по корректной подготовке текста к публикации
следующая:

1. Подробите текст на части, примерно по 30К ─ как по-
казывает опыт, такой размер обычно свободно пропускается бо-
льшинством программного обеспечения сетей. Hе забудьте заме-
нить в нём везде заглавную русскую букву "H" на латинскую
"H", иначе она неминуемо будет "съедена" программным обеспе-
чением FTN, а ваш текст повреждён. Это распространённая оши-
бка, совершаемая многими по невнимательности и нередко при-
водящая к конфузам. :-)

2. В н а ч а л е каждой секции вставьте строку вида:

textsection X of Y of file FILENAME

где:

X ─ номер данной секции;
Y ─ общее количество секций;
FILENAME ─ имя файла данного текста.

Если текст состоит всего из одной секции, то X = Y = 1.
Hепосредственно з а н е й поместите ещё строку ви-
да:

textbegin.all ─ если это 1-я секция
textbegin.section ─ если это прочие секции

Эти строки указывают начало блока публикуемого текста.
Всё, что находится до них, к тексту не относится, и там вы
можете поместить предваряющие комментарии и всё остальное,
что вам заблагорассудится. Извлечение секции начнётся только
с этих строк.

3. В к о н ц е каждой секции вставьте строку вида:

textend.all ─ если это последняя секция
textend.section ─ если это прочие секции

Эта строка обозначает конец блока публикуемого текста.
Всё, что находится за ней, к тексту не относится, и точно
так же будет пропущено при извлечении.
Т.о. вы можете снабжать секции какими угодно коммента-
риями в начале и в конце и даже вставлять ограниченные этими
строками секции посреди своих писем ─ опираясь на эти строки
программа аккуратно разыщет все секции в базе, в каком бы
месте сообщения они ни находились, состыкует и отправит в
готовый файл, подобно тому, как автоматически извлекается
UUE-код, и ваш получатель будет избавлен от ненужных неуд-
обств и траты времени на ручную сборку.
Собственно, на этом можно и закончить. Следуя 3 пунктам
выше, вы можете приступать к постингу текстов, на порядок
более ц и в и л и з о в а н н о м у , чем вы делали это
раньше.
Дальше, педантичности ради, следует упомянуть лишь ряд
незначительных технических деталей.
Стандарт sergey korowkin предусматривает ряд второсте-
пенных строк между textsection и textbegin вида:

textauthor имя автора
textinfo какая-либо информация
textstd версия стандарта (в данном случае 0.1)

Вы можете придумать и какие-то свои аналогичные строки;
программы, очевидно, их проигнорируют, но собственно нужны
они больше не для программ, а для читателей.
Стандарт также предусматривает инвалидацию ключевых по-
следовательностей вышеперечисленных строк в самом тексте,
если они там есть, чтобы извлекающая программа не приняла их
по ошибке за настоящие. Т.е. если в самом вашем тексте
встречаются строки, начинающиеся с последовательностей:

begin
section
textbegin.all
textbegin.section
textend.all
textend.section
textsection
\

их нужно заменить на:

\begin
\section
\textbegin.all
\textbegin.section
\textend.all
\textend.section
\textsection
\\

соответственно.
Впрочем, как вы сами уже догадались, строки эти (за ис-
ключением, разве, "begin" и "section" для текста на английс-
ком) словами человеческого языка не являются и вероятность
встретить их в обычном тексте близка к нулю, так что и с не-
обходимостью думать об этом вы в реальной жизни, скорее все-
го, не столкнётесь. :-) Исключением явился только сам этот
текст.
Помещайте тексты в эхоконференции только в т а к о м
виде. Имейте в виду, что простая вставка кусков текста в
значительной мере с н и ж а е т ценность того, что вы за-
постили т.к. "выдрать" его из базы сообщений для того, чтобы
сохранить или передать кому-то другому, потом крайне сложно.
Потрудившись чуть-чуть сами, вы сэкономите массу времени
множеству других людей.
Вот как выглядит реальный пример оформленного таким об-
разом постинга текста, разбитого на 10 секций:

textsection 1 of 10 of file navigator.txt
textauthor Владимир Высоцкий
textinfo пример оформления постинга текста
textstd 0.1
textbegin.all
Вот послал господь родителям сыночка;
Люльку в лодку переделать велел:
Мореплаватель родился ─ одиночка;
Сам укачивал себя, сам болел.

textend.section

textsection 2 of 10 of file navigator.txt
textbegin.section
Hе по году он мужал ─ по денёчку, ─
И уже из колыбели дерзал;
К мореплаванью готовясь в одиночку,
Из пелёнок паруса вырезал.

textend.section

textsection 3 of 10 of file navigator.txt
textbegin.section
Прямо по носу, глядите:
То ли бочка, то ли яхта, то ли плот, то ли нет...
Мореплаватель, простите, одиночка,
Посылает вам салют и привет.

textend.section

textsection 4 of 10 of file navigator.txt
textbegin.section
Ой, ребята, не к добру проволочка.
Сплюньте трижды все, кто на корабле:
Мореплаватель на море, одиночка, ─
Вроде чёрного кота на земле.

textend.section

textsection 5 of 10 of file navigator.txt
textbegin.section
Вы откуда? Отвечайте нам и точка.
Hе могли же вы свалиться с небес.
Мы слыхали, что какой-то одиночка,
В треугольнике бермудском исчез.

textend.section

textsection 6 of 10 of file navigator.txt
textbegin.section
Это утка, это бред ─ всё до строчки.
И простите, если резок и груб.
Мореплаватели знают, одиночки, ─
Он совсем не треугольник, а куб.

textend.section

textsection 7 of 10 of file navigator.txt
textbegin.section
Вот добавил он в планктон кипяточку.
Как орудует ─ хоть мал, да удал!
Глядь, и есть деликатес в одиночку.
А из нас таких никто не едал.

textend.section

textsection 8 of 10 of file navigator.txt
textbegin.section
Hе искусственную ли оболочку
Вы вокруг себя мой друг возвели?
Мореплаванью, простите, в одиночку
Hаше общество предпочли.

textend.section

textsection 9 of 10 of file navigator.txt
textbegin.section
Он ответил: "Вы попали прямо в точку.
Там, на суше, не пожать мне вам руки:
В море плавая подолгу, в одиночку,
Я по людям не скучал, моряки".

textend.section

textsection 10 of 10 of file navigator.txt
textbegin.section
Так поменьше им забот и отсрочек,
И задорин на пути, и сучков!
Жаль, что редко мы встречаем одиночек ─
Hепохожих на других чудаков,
Жаль, что редко мы встречаем одиночек ─
Славных малых, озорных чудаков.
textend.all


... А меж тем, в правилах есть что-то интересное... ;-)
> Письма из Интернета шлите на 2:5020/1317.8
√ Origin: AKA: 2:5020/794.15, /1317.8, /1452.3, /2613.5 (2:5020/2613.5)
───────────────────────────────────────────────────────────────────────────────

MtW>> А вот другое применение. Представим себе эхоконференцию, подписчики
MtW>> которой обмениваются занимательными картинками (смешными или
MtW>> познавательными) в UUE, причём в правилах эхи записано, что все они
MtW>> должны иметь одно и то же имя файла (допустим, greatpic.jpg). Тогда
MtW>> area://Ru.Great.Pictures/greatpic.jpg всегда будет указывать на самую
MtW>> последнюю такую картинку. Можно не читать саму эху,
MtW>> но навесить себе эту картинку куда-нибудь и созерцать её обновление.
MtW>> Получится весьма созерцательно.
DR> Созерцательно. Hо не функционально. см. абзац выше. Если ты хочешь, чтобы
DR> широкая общественность пошла тебе навстречу - попробуй все-таки сам пойти
DR> навстречу.

Я, собственно, не улавливаю причин для недовольства широкой общественности.
Особенно относительно данного примера. Не функционально что именно?

MtW>> Третье применение касается FFF (FGHI Fidosphere Features), и, в
MtW>> частности, такой особенности, как аватары (они же юзерпики) пойнтов и
MtW>> нод. Предположим, что кто-нибудь выкладывает свои юзерпики в некоторую
MtW>> эху. Если задано, что его 'грустный' юзерпик имеет URL вида
MtW>> area://Some.Echo/sad.gif?from=2:345/678.9, то этот пойнт может сменить
MtW>> свой юзерпик, просто положив новый sad.gif в ту же эху (ему не придётся
MtW>> делать более никаких дополнительных для этого телодвижений).
DR> Эхи - неподходящий инструмент для этого. Ты видел, чтобы на форуме
DR> отдельным постом кто-то выкладывал юзерпик?

А если это его собственная эха? 'Кто хочет видеть мои юзерпики ── подпишитесь
на PVT.My.Userpics с ресканом!'

MtW>> Почему, в конце концов, по файлэхам могут приходить обновления файлов,
MtW>> а по обычным эхам нет?
DR> Потому что эхи не предназначены для пересылки обновлений в частности
DR> и файлов в общем. В виде исключения допускается файл, дополняющий само
DR> письмо.

Понимаешь, какая штука: создание стандартов адресации объектов Фидонета ──
это всё же не политика, а технология. Может быть, эхи не предназначены в общем
для пересылки файлов, но существует и немало эх, именно для пересылки файлов
использующихся! Я не собираюсь использовать создание стандарта адресации
в качестве средства давления на какие-то методы передачи файлов по Фидонету
(для которых Фидонет, по моему или чьему-либо другому мнению, не приспособлен
и не предназначен) в пользу каких-то других методов, которые мне или кому-то
другому покажутся более правильными. Пусть все эти методы будут в совершенно
равной степени удобными с точки зрения адресации. Сообщество должно будет
сделать выбор, исходя из каких-то других соображений, но не этих. Стандарт,
искусственно ограниченный, очень часто оказывается совершенно нежизнеспособным.
Вспомни кладж GIF в GoldEd, который предполагал, что юзерпики будут храниться
только в GIF и раздаваться только по фрекам ── кто его поддержал, кроме GoldEd?
Вспомни FIPSовый мультимедиа-пакет, который предполагал, что юзерпики будут
храниться в формате BMP (да ещё и не более чем 256-цветном! прости их, Господи)
и рассылаться только роботом в нетмейле по предварительному запросу, которому
должен предшествовать ещё более предварительный запрос правил общения с этим
роботом ── кто поддержал этот пакет, кроме FIPS?

Я не собираюсь ограничивать своим стандартом реальность сегодняшнего дня.
Я стараюсь только вырастить на её основе какую-нибудь такую реальность
завтрашнего дня, которая бы не вырастала слишком уродливою. Но корни не трогаю.
Если ограничения не вызваны соображениями безопасности и удобства, я не желаю
вносить их.

MtW>> И заметь, что я совершенно не спорю с тем, что возможность адресовать
MtW>> файлы навроде
MtW>> area://Ru.Fidonet.Today/pangram.png?msgid=2:5020/545+48560d98&t
MtW>> ime=2008 (то есть по msgid и году) должна быть. Я просто хочу сказать,
MtW>> что это вряд ли должен быть именно единственный возможный способ.
MtW>> Могут и должны быть и другие.

DR> Пусть будет лучше единственный способ. Возможно потом альтернативные
DR> можно будет придумать, но HЕ HА ОСHОВЕ ФИЛЬТРА! Это однозначно. Так
DR> намного удобнее с точки зрения реализации. Hе надо из множества
DR> выискивать файл по одной ссылке.

DR> Hу если уж так хочется задействовать поисковую систему редактора, то лучше
DR> написать тогда что-нибудь типа
DR> area://ru.ftn.develop/msgid=2:478/37+*/archive.zip/image1.gif?time=2008
DR> То есть однозначно указать, что это не ссылка на эху, а ссылка на
DR> МHОЖЕСТВО ФАЙЛОВ по маске, которые отфильтрованы уже потом.

Вот тут я тебя потерял. С одной стороны, ты полагаешь, что с точки зрения
реализации удобнее, чтобы фильтра не было, чтобы не выискивать из множества
файл. С другой стороны, тебе удобно найти множество файлов по маске, а потом уж
их отфильтровывать. Это как-то противоречиво, мне кажется. Может быть, проще
отфильтровать сперва сообщения, а потом уж искать файл в них по заданному его
имени? Ещё обрати внимание на совет, в разделе 7.2.1 FGHI URL предлагаемый:

СОВЕТ ПО ИСПОЛНЕНИЮ: скорость вычисления МОЖЕТ быть улучшена
самим фактом того, что итоговое множество всегда является
пересечением типовых множеств подытога. Сообщение ДОЛЖНО
появиться в каждом из типовых множеств подытога, чтобы стать
частью итогового множества. И поэтому, если одно из типовых
множеств подытога уже вычислено, все остальные фильтры сообщений
МОЖНО применять к этому типовому множеству подытога вместо
первоначального множества сообщений: вполне безопасно пропускать
те сообщения, которые имеются в первоначальном множестве
сообщений, но отсутствуют в этом типовом множестве подытога,
поскольку они в любом случае не появятся в итоговом множестве
сообщений.

Пример: если заданный URL содержит несколько фильтров типа
"msgid" и несколько фильтров типа "find", тогда разумно начать
с вычисления типового множества подытога для типа "msgid" (оно,
скорее всего, будет содержать всего-то несколько сообщений);
затем вполне безопасным будет применение поисков "find" только
к сообщениям этого более узкого множества, что избавит нас от
надобности проглядывать через всё первоначальное множество.

Кроме того, как мне кажется, ты переоцениваешь необходимость 'однозначно
указать, что это не ссылка на эху, а ссылка на МHОЖЕСТВО ФАЙЛОВ по маске,
которые отфильтрованы уже потом'. Ради этой необходимости ты, как мне кажется,
вполне готов взять мою 'ссылку на эху', которая имеет примерно такой вид:

area://ru.ftn.develop/archive.zip/image1.gif

и придать ей такой (совершенно эквивалентный, но более длинный) вид:

area://ru.ftn.develop/msgid=*/archive.zip/image1.gif

Мне кажется ещё, что msgid-часть тут совершенно лишняя.

MtW>> Множество писем, состоящее из одного письма ── это и есть одно это
MtW>> письмо. Нет никакой разницы. Нет никакой неоднозначности.
DR> Есть разница. Это разные классы. При реализации это достаточно серьезная
DR> неоднозначность. Или если у нас в эхе только одно письмо, то по твоей
DR> логике эта эха и это письмо есть одно и то же.

Какая разница в реализации между письмом и множеством писем (которое, с точки
зрения реализации, является направленным списком или динамическим массивом),
которое содержит одно письмо? Разница эта существует, конечно, с этим не спорю;
но разница эта невелика. Эта разница состоит в паре-тройке-другой десятков
операторов языка высокого уровня. Ты бы желал, чтобы в URLе, ведущем к файлу,
всегда было только одно письмо, выбранное всегда одним и тем же фильтром, и ещё
всегда одна (не более чем одна) эха; тогда твой алгоритм получения файла будет
примерно таков:

эха = эхолист.выбратьЭхуПоАреатагу(URL.ареатаг);
письмо = эха.взятьПисьмоПоMSGID(URL.msgid);
если (URL.путьКФайлу не пуст) то
файл = письмо.декодироватьФайл(URL.путьКФайлу)
окончание тела если;

если файл то ...обработка файла...

А я вот допускаю в этом URLе сколько угодно ареатагов и фильтров и писем; тогда
алгоритм получения файла использует цикл с возможным выходом из середины:

эхи = эхолист.выбратьЭхиПоАреатагам(URL.ареатаги);
множество = эхи.взятьВсеПисьма();
множество.фильтровать(URL.фильтры);
если (URL.путьКФайлу не пуст) то
пока ((письмо = множество.взятьСледующееПисьмо()) не пусто) делать
файл = письмо.декодироватьФайл(URL.путьКФайлу);
если файл то конец цикла пока;
окончание тела цикла пока;
окончание тела если;

если файл то ...обработка файла...

Спрашивается: где тут неоднозначность? Чуть-чуть больше сложности, не более!
Вот вся разница, вот все эти сложности:

*) новый объект 'эхи' ── он содержит список или динамический массив эх;

*) новый объект 'множество' ── содержит список или динамический массив писем;

*) новая функция 'множество.фильтровать()' сложнее, чем взятьПисьмоПоMSGID();

*) новая функция 'эхи.взятьВсеПисьма()', создающая и возвращающая множество;

*) новая функция 'множество.взятьСледующееПисьмо()' ── очень простая, очевидная
в реализации.

MtW>> Смысл вопросительного знака в URLе очень прост -- отметить то место, с
MtW>> которого начинается необязательная часть URLа, состоящая из пар
MtW>> параметр=значение. Единственной обязательной частью адреса письма (или
MtW>> нескольких писем) является ареатаг эхи (или несколько ареатагов
MtW>> нескольких эх). Все остальные параметры необязательны: и фильтры,
MtW>> сужающие множество сообщений, и прочие необязательные параметры,
MtW>> контролирующие отображение этого множества.
DR> msgid тоже обязательная часть, если нам надо отобразить письмо или его
DR> часть (в т. ч. и файл). А вот если нам надо именно отобразить первое
DR> письмо из некой груп, то можно использовать "*",

Я выше сказал уж и ещё повторю: ты используешь 'msgid=*' там, где у меня стоит
пустота. Сделай этот параметр необязательным, и ты обретёшь экономию усилий.

MtW>> Пока не вижу, почему это именно на порядок легче. Ведь если во
MtW>> множестве одно письмо, то всё остальное происходит точно таким же
MtW>> образом, как если бы это всегда могло бы быть только одно письмо и не
MtW>> более. Разница только
DR> Письмо не есть множество из одного письма.

Письмо есть результат первого вызова функции множество.взятьСледующееПисьмо().
Неужели реализация этой функции столь сложна, что за её отсутствие ты борешься?

MtW>> в том, что во множестве может быть и не одно письмо. о эта разница к
MtW>> добру, а не к худу: она открывает доступ к нескольким полезным
MtW>> возможностям.
DR> Оно будет с граблями однозначно. А так - фтопку такие возможности. Hадо
DR> все-таки разумно подходить к вопросу.

Ты всё ещё не показал мне вообще никаких граблей.


Фидонет будет великим и гипертекстовым! [Ru.Mozilla] http://Mithgol.Ru/
Mithgol the Webmaster. [Братство Нод] [Team А я меняю subj]

... Кольцо ── это не более чем дискета с бэкапом Саурона!.. (C) unknown
--- Эшелону: президент ISFR ISSO walburn шестой Дефкон DC6 Larson P99 кокаин
* Origin: у меня такое чувство, словно и раньше испытывал дежа вю (2:5063/88)