PG>> Но я сравниваю файлэхи и (гипотетические) файлаттачи в echomail, а не PG>> наличие файлэх с их отсутствием. Технически - возможно, у эхопроцессора в PG>> описании эхи нужно было бы добавить ключик, разрешающий файлаттачи, и PG>> каталог, куда их складывать.
SD> Если бы это было бы реализовано в софте, мало бы где это толком работало.
Очевидно, это зависит от того, как было бы реализовано. ;-)
SD> Вот например, пришёл пакет, в нём сообщение с аттачем остальные без. А файла в инбаунде нет. SD> Что делать? SD> Тормозить весь пакет? SD> Разбивать, тоссить что можно, сообщение с аттачем класть в "ожидающее"? SD> Сильно усложняется тоссинг, много косяков будет. SD> А если не дай Б-г какой дурак напишет в стандарте, что "файл должен прийти перед бандлом", аффтары софта так вообще болт SD> забьют и половина доходить не будет.
Это частный технический вопрос. Вариант: паковать приаттаченные файлы в тот же бандл, где pkt. Другой вариант: да, сообщение класть в "ожидающее" (например, делать pkt в inbound или оставлять в отдельном каталоге). Не вижу, чем это сложнее, чем tic, ожидающий своего файла. Третий вариант: да, файл перед бандлом. Чай, не на диалапе живём - не вижу существенных недостатков. А если файлов много-много и они передаются долго-долго, скажем, 8 часов, то всё равно ведь на время передачи файлов netmail и echomail будут ожидать. Четвёртый вариант: сделать новый формат pkt, в который можно помещать бинарные файлы, и паковать файлы в один pkt с мессагами, к которым они приаттачены.
В общем, это не является неразрешимой или даже сложной проблемой.
Lucky carrier, Паша aka gul@gul.kiev.ua --- GoldED+/LNX 1.1.5 * Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68)
