= Сообщение: 38124 из 47125 =============================== RU.FIDONET.TODAY = От : Alexey Fayans 2:5030/1997 12 Oct 23 12:28:28 Кому : Stas Mishchenkov 12 Oct 23 12:28:28 Тема : Binkd - это звонилка, а не комбайн! FGHI : area://RU.FIDONET.TODAY?msgid=2:5030/1997@fidonet+6527bc3f На : area://RU.FIDONET.TODAY?msgid=2:460/5858+6527ab6c = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Hello Stas!
On Thu, 12 Oct 2023, at 11:12 +0300, you sent me a message:
AF>> Ты утверждаешь, что гонять файлы по роутингу, задействуя при этом AF>> один или более промежуточный узел - это более эффективное AF>> использование ресурсов сети, чем выкладывание файла на холд с AF>> уведомлением? Серьёзно? SM> Я утверждаю, что родилось по тому, что роутинг не работал.
С этого мы начали.
SM> И я утверждаю, что гонять файл через транзитные узлы эффективней, чем SM> гонять его ююк.
Я написал, что холд был придуман скорее из-за того, что роутинг аттачей крайне неэффективно использует ресурсы сети. В ответ на утверждение, что холд придумали из-за того, что роутинг аттачей не работал. То есть я сравниваю роутинг аттачей и холд.
На это ты отвечаешь: "Вот уж точно - нет. Наоборот". То есть ты утверждаешь, что роутинг аттачей эффективнее холда по части использования ресурсов сети.
Я понимаю, что ты забежал вперёд и ответил уже про другое, но давай всё-таки не будем рушить логику.
А не работал роутинг аттачей, скорее, потому, что никому нафиг не нужно было такое городить при наличии более эффективных способов доставки файлов.
AF>> В смысле больше? У меня это одной кнопкой делается. SM> Это хорошо, что ты автоматизировал это для себя. Обычно же это не так.
Писать сложные скрипты на перле для тебя нормально, а написать примитивнейший скриптик для холда с уведомлением - нет? В любом случае, есть готовые решения для этого, например:
=== Start of Windows Clipboard === ╔════╣ Attach & Info v.1.12 ╠═════╗ ║ Делает Аттач/Холд файлов с ║ ║ уведомлением, что файл положили ║ ║ на холд или проаттачили. ║ ╟─────────────────────────────────╢ ║ √ Аттач/Холд файлов по списку ║ ║ (Файлов или адресов) ║ ║ √ Режимы мылеров: ║ ║ - Arcmail-Attach ║ ║ - Bink ║ ║ - FileBoxes(all) ║ ║ √ Достает из ЛЮБЫХ архивов ║ ║ File_Id.Diz и вставляет в ║ ║ уведомление. ║ ║ √ Уведомление по шаблону ║ ║ √ Прикручивается к оболочкам ║ ║ √ Текстовые конфиги ║ ║ √ FREEWARE! ║ ║ √ И многое другое ║ ╟─────────────────────────────────╢ ║ (c) 1999-2000 Sasha Leshinsky ║ ╚═════════════════════════════════╝ === End of Windows Clipboard ===
SM>>> Ну, да. Отправить на треть больше по размеру, да, ещё и pkt не SM>>> докачиваются. Диалапные узлы точно спасибо скажут. А ещё по пути SM>>> найдётся сисоп, который просто вернёт тебе эту мессагу с SM>>> припиской, что, вот, на такое он точно не подписывался. AF>> А на нетмейл с аттачами в виде обычных файлов он, конечно же, AF>> подписывался. SM> Аттач - это свойство нетмейла, а на нетмейл он поджписывался.
Текст - тоже свойство нетмейла. Причём основное. А UUE - это текст.
AF>> Из двух зол я предпочитаю выбирать меньшее, поэтому если директом AF>> человеку файл не отправить, и необходимо обязательно использовать AF>> для передачи файла FTN, то мой выбор - UUE. Тем более, что его AF>> можно разбить на секции и отправлять хоть по одной секции в AF>> час/день/неделю, если уж там какие-то проблемы со связью. SM> В итоге секция потеряется и файл не соберётся.
Секцию можно переотправить, это вообще не проблема. Да и вероятность такого события ничтожна.
