Исходное сообщение
"транспорт: вот не надо ориентироваться на SMTP" Отправлено gvy, 14-Июл-07 11:34
>>>котором можно будет это проверить. А вообще, самое простое решение для >>>репликации (сейчас придумал) -- пересылка бэкапа базы по мейлу, в автоматическом >>>режиме. >>Но, вам такого не простят если речь пойдет о приличном заказчике Или просто при наличии у него грамотных специалистов. >>нужен продуманный движек с интерфейсом для плагинов под smtp/ftp и >выгрузка в текстовый файл -> упаковка _> smtp -> распаковка -> зарузка в базу. >зачем усложнять? Видите ли. При помощи SMTP Вы абстрагируетесь от транспорта (включая асинхронную доставку), а взамен выгребаете все проблемы этого самого SMTP: раздувание бинарных данных, пересечение с достаточно сложной и хрупкой на сейчас системой на обоих концах (smtpd+clamav+spamd практически по минимуму) и риск подвергнуть бизнес-операции не относящимся к ним техническим деталям (вроде "антивирь подавился дампом" или "IP попал в RBL"). Меня при виде такого беспечного "зачем усложнять", честно говоря, передёрнуло ещё сильней, чем при виде "нормальный портедж".  Поскольку в 2002--2003 прикручивали одну систему доставки мобильного контента к двум местным крупным мобильным операторам.  У одного был самопальный, но грамотно сынженеренный XML-RPC.  А вот у другого -- под грифом "секретно" или какая там тайна документация на самопальную систему доставки, которая в качестве транспорта использовала... SMTP! Причём по стилю документации было кристально ясно, что дай этим фи... фидошникам волю, там бы в качестве требований по развёртыванию непременно был T-Mail и на поклон к боссу с пивом. И как думаете -- не было проблем?  Ещё как "не было". Я это всё к чему. Не надо мешать мух и котлеты.  Почта может применяться как крайний, аварийный, для вырожденных случаев, в которых ничего больше просто не остаётся, случай. Иначе лучше использовать rsync (возможно, over ssh; эта комбинация умеет и докачку, и компрессию, и шифрование, и аутентификацию с доступом по ключу), HTTP, да хоть XMPP, только не SMTP. О проблемах с поддержкой Gentoo и портообразных в течение длительных сроков времени тоже есть что сказать (особенно по библиотечной части и прочим стыковкам API), но это не относится к прибитым в продукт вещам обычно.  В отличие от транспорта. >А если канал толстый -- то, лучше всякой репликации -- >общая база данных. Вы проверяли?  Есть мнение, что в таких случаях бывает проще терминальный режим работы того, чего в итоге написывается, чем удалённая база.  Вообще исходить из того, что канал толстый, ресурсов дофига, а пользователи не ошибаются -- типичные стартовые ошибки, которых не стоит допускать даже на старте.  Поскольку прототипы действительно мало где в итоге переписывают. Плюс к тому стоит иметь в виду, что каналы бывают толстые, но латентные (особенно спутник или через кудыкины штаты). >>ЗЫ не понял кстати что значит бэкап базы, может все таки измененных >>данных подлежащих синхронизации? >Бэкап базы филиала [дилера], для слияния с основной базой. Ну и, соответсвенно, >изменения в ценах ассортименте, вообще -- в справочниках -- в другую >сторону. Это для нашего полигона. Опять же надеюсь, что Вы заранее видите проблему с масштабируемостью этого подхода без костылей вроде досрочного архивирования базы.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>>>котором можно будет это проверить. А вообще, самое простое решение для >>>>репликации (сейчас придумал) -- пересылка бэкапа базы по мейлу, в автоматическом >>>>режиме. >>>Но, вам такого не простят если речь пойдет о приличном заказчике > Или просто при наличии у него грамотных специалистов. >>>нужен продуманный движек с интерфейсом для плагинов под smtp/ftp и >>выгрузка в текстовый файл -> упаковка _> smtp -> распаковка -> зарузка в базу. >>зачем усложнять? > Видите ли. > При помощи SMTP Вы абстрагируетесь от транспорта (включая асинхронную доставку), а взамен > выгребаете все проблемы этого самого SMTP: раздувание бинарных данных, пересечение с > достаточно сложной и хрупкой на сейчас системой на обоих концах (smtpd+clamav+spamd > практически по минимуму) и риск подвергнуть бизнес-операции не относящимся к ним > техническим деталям (вроде "антивирь подавился дампом" или "IP попал в RBL"). > Меня при виде такого беспечного "зачем усложнять", честно говоря, передёрнуло ещё сильней, > чем при виде "нормальный портедж". Поскольку в 2002--2003 прикручивали одну > систему доставки мобильного контента к двум местным крупным мобильным операторам. > У одного был самопальный, но грамотно сынженеренный XML-RPC. А вот > у другого -- под грифом "секретно" или какая там тайна документация > на самопальную систему доставки, которая в качестве транспорта использовала... SMTP! > Причём по стилю документации было кристально ясно, что дай этим фи... фидошникам > волю, там бы в качестве требований по развёртыванию непременно был T-Mail > и на поклон к боссу с пивом. > И как думаете -- не было проблем? Ещё как "не было". > Я это всё к чему. > Не надо мешать мух и котлеты. Почта может применяться как крайний, > аварийный, для вырожденных случаев, в которых ничего больше просто не остаётся, > случай. > Иначе лучше использовать rsync (возможно, over ssh; эта комбинация умеет и докачку, > и компрессию, и шифрование, и аутентификацию с доступом по ключу), HTTP, > да хоть XMPP, только не SMTP. > О проблемах с поддержкой Gentoo и портообразных в течение длительных сроков времени > тоже есть что сказать (особенно по библиотечной части и прочим стыковкам > API), но это не относится к прибитым в продукт вещам обычно. > В отличие от транспорта. >>А если канал толстый -- то, лучше всякой репликации -- >>общая база данных. > Вы проверяли? Есть мнение, что в таких случаях бывает проще терминальный > режим работы того, чего в итоге написывается, чем удалённая база. > Вообще исходить из того, что канал толстый, ресурсов дофига, а пользователи > не ошибаются -- типичные стартовые ошибки, которых не стоит допускать даже > на старте. Поскольку прототипы действительно мало где в итоге переписывают. > Плюс к тому стоит иметь в виду, что каналы бывают толстые, но > латентные (особенно спутник или через кудыкины штаты). >>>ЗЫ не понял кстати что значит бэкап базы, может все таки измененных >>>данных подлежащих синхронизации? >>Бэкап базы филиала [дилера], для слияния с основной базой. Ну и, соответсвенно, >>изменения в ценах ассортименте, вообще -- в справочниках -- в другую >>сторону. Это для нашего полигона. > Опять же надеюсь, что Вы заранее видите проблему с масштабируемостью этого подхода > без костылей вроде досрочного архивирования базы.
	Введите код, изображенный на картинке: