>Видите ли.
>
>При помощи SMTP Вы абстрагируетесь от транспорта (включая асинхронную доставку), а взамен
>выгребаете все проблемы этого самого SMTP: раздувание бинарных данных, пересечение с
>достаточно сложной и хрупкой на сейчас системой на обоих концах (smtpd+clamav+spamd
>практически по минимуму) и риск подвергнуть бизнес-операции не относящимся к ним
>техническим деталям (вроде "антивирь подавился дампом" или "IP попал в RBL"). ну. во-первых это все прописывается в конфигах антивиря, антиспама и т.д., дабы пропускать без задержек и проверок. И какое дело двум хостам, что оба они в RBL, если у них четкая инструкция -- передавать друг другу указанные файлы по SMTP, без проверок. А для защиты перенаправим SMTP в ssh. А файл зашифровать. Есть коннект -- передаются данные, нет коннекта -- ожидают. Это там где каналы безобразные.
Но, в любом случае, способ передачи файлов не относится к оперативному учету непосредственно. Это, всего лишь, часть процедуры синхронизации(репликации) данных. И еще неизвестно, может быть она не потребуется. Ведь бизнес-процесс можно тоже немного переориентировать.
>
>
>Меня при виде такого беспечного "зачем усложнять", честно говоря, передёрнуло ещё сильней,
>чем при виде "нормальный портедж". Поскольку в 2002--2003 прикручивали одну
>систему доставки мобильного контента к двум местным крупным мобильным операторам.
>У одного был самопальный, но грамотно сынженеренный XML-RPC. А вот
>у другого -- под грифом "секретно" или какая там тайна документация
>на самопальную систему доставки, которая в качестве транспорта использовала... SMTP!
шифрованный файл по SMTP в туннель и ничего страшного.
>
>Причём по стилю документации было кристально ясно, что дай этим фи... фидошникам
>волю, там бы в качестве требований по развёртыванию непременно был T-Mail
>и на поклон к боссу с пивом.
можно и UUCP вспомнить, хороший же протокол .. для некоторых задач :-)
>
>И как думаете -- не было проблем? Ещё как "не было".
>
>
>Я это всё к чему.
>
>Не надо мешать мух и котлеты. Почта может применяться как крайний,
>аварийный, для вырожденных случаев, в которых ничего больше просто не остаётся,
>случай.
>
>Иначе лучше использовать rsync (возможно, over ssh; эта комбинация умеет и докачку,
>и компрессию, и шифрование, и аутентификацию с доступом по ключу), HTTP,
>да хоть XMPP, только не SMTP.
а я и не спорю против rcync. Возможно это даже самый оптимальный способ.
>
>О проблемах с поддержкой Gentoo и портообразных в течение длительных сроков времени
>тоже есть что сказать (особенно по библиотечной части и прочим стыковкам
>API), но это не относится к прибитым в продукт вещам обычно.
смотрю на Linux-зоопарк, и вопросы поддержки того или иного ПО всплывают постоянно, в любых дистрибутивах. Вот, например, SuSe и GPLv3 -- уже всплывают вопросы .. :-)))
Перепробовал RedHat (с 6.1),Mandrake/Mandriva (с 8-ки), SuSe, Slackware, Debian, Ubuntu. Остановился на Gentoo. Самый POSIX-ный дистрибутив и гибкий. Это все равно, что с Windows на Mandriva переходишь, а назад никак. Так вот с Gentoo на Mandriva -- тоже никак. :-))
>>А если канал толстый -- то, лучше всякой репликации --
>>общая база данных.
>
>Вы проверяли? Есть мнение, что в таких случаях бывает проще терминальный
>режим работы того, чего в итоге написывается, чем удалённая база.
Какой полосы хватает терминальнолму клиенту при диалапе? 44 кбит/сек хватит?
Виндовому нет, X -- с трудом, VNC - чуть получше. А дял серфинга -- хватает. Но тут вопрос -- а хватит ли времени удаленному клиенту выполнить транзакцию и выписать нужный товар на скорости 44 кбит/сек, когда его коллега, сидя в офисе выписывает тот же самый [последний] товар на канале в 100Мбит?
>Вообще исходить из того, что канал толстый, ресурсов дофига, а пользователи
>не ошибаются -- типичные стартовые ошибки, которых не стоит допускать даже
>на старте. Поскольку прототипы действительно мало где в итоге переписывают.
см. выше.
>>>ЗЫ не понял кстати что значит бэкап базы, может все таки измененных
>>>данных подлежащих синхронизации?
>>Бэкап базы филиала [дилера], для слияния с основной базой. Ну и, соответсвенно,
>>изменения в ценах ассортименте, вообще -- в справочниках -- в другую
>>сторону. Это для нашего полигона.
>
>Опять же надеюсь, что Вы заранее видите проблему с масштабируемостью этого подхода
>без костылей вроде досрочного архивирования базы.
ну что-то видим, что-то Вы подсказываете :-))
