Здравствуйте, Mamut, Вы писали:
M>Unix-way подразумевает вызов faxsend для получения некоторого структурированного списка папок и сообщений. Этот список еще надо будет ручками распарсить и прийти, в общем, к такому же коду, что я привел, но с бОльшим геморроем (парсер-то придется писать).
Вот насчет распарсить ручками -- это еще вопрос
Если бы faxsend был восстребованн именно в виде автономного приложения, то для парсинга его результатов уже давно были бы готовые библиотеки (вроде C++ оберток над PCRE или zlib). Возможно, даже созданные с помощью yacc/lex или antlr.
M>Тут есть еще один грабель — пути к исполняемым фалам. В *nix же тоже есть переменная окружения PATH 
(это если я не ошибаюсь) То есть, faxsend на самом деле придется запускать как-то так:
M>M>/usr/local/faxsend/bin/faxsend --faxlist
M>
Вот это спорное утверждение, имхо (на счет полного пути к faxsend).
M>А faxsend не обязательно в той папке находится В случае с COM'ом нам достаточно, чтобы WinFax был просто установлен в системе.
"Просто установлен"
Помнится довелось с HTTP работать через WinInet. Так приложение сильно зависело от того, какая версия IE была на машине установлена.
В случае с внешним приложением его можно таскать с собой и запускать из собственного подкаталога. Причем именно ту версию, которую нужно. Например, я так Ruby с собой таскал, когда нужно было у заказчиков контрольную компиляцию делать.
На самом деле интересен подход в стиле Unix way в TIB/Rendezvous. Там демоны-router-ы работают как отдельные приложения на каждой из машин. А локальные приложения, нуждающие в TIB/Rendezvous, подключаются к локальному демону. Причем протокол там собственный, двоичный, но, тем не менее, явное разделение на компоненты, отвечающие только за одну задачу. А общение между компонентами происходит посредством библиотеки, поддерживающей протокол общения с локальным демоном. Поскольку общение с демоном идет через TCP/IP, то вместо локального демона можно легко подключится к удаленному (например, на ноутбуке пользователя может не быть локального демона, зато на его рабочей станции -- будет).
Так что Unix way можно рассматривать как стремление разнести разные задачи по разным процессам и избежать работы через общее адресное пространство и RPC механизмы. Поскольку такой подход дает надежность, масштабируемость и расширямость. Но ценой некоторых издержек. В том числе и по объему первоначального кодирования.
Просто примеры удобнее всего приводить с использованием стандартных утилит вроде tar, bzip, find, xarg, grep. Их использование в сочетании с конвейерами является наглядной, но далеко не полной иллюстрацией Unix way.
Но лично я не пытаюсь доказать, что Unix way лучше, чем COM или какая-то другая компонентная модель. Только хочу показать, что, имхо, компонентные технологии стремяться к монолитным приложениям, в которых компоненты взаимодействуют через вызовы процедур (будь то локальный вызов, или обращение к удаленному объекту посредством RPC). В то время как Unix way явно рекомендует вместо монолитных приложений создавать раздробленные на небольшие части приложения и организовывать взаимодействие между ними через другие формы IPC (а RPC следует избегать). Но без фанатизма.
