Этот сайт — моя персональная записная книжка. Интересны мне, по большей части, программирование, история и события из моей жизни.
Такой молодой Python
Девятнадцать лет языку, а модуля для него, который поддерживал бы сочетание SOAP+NTLM+HTTPS+WSDL-от-Excahnge 2007 так и нет. Ни одна из SOAP библиотек для Python не умеет это всё сразу. И большинство из них даже не смогли разобрать (полностью валидный) WSDL SOAP Exchange 2007!
Вот удивительно… Есть дико переусложнённый стек технологий, которые несовместимо меняются чуть не каждый год, и которые были *специально спроектированы* не для решения проблем, а для продажи инструментов по их обслуживанию. И теперь то, что в Питоне нет адекватных средств для работы с этой кучей хлама -- это проблема Питона?
P.S. Я знаю, что тебе надо практическую задачу решить. Но меня смещение акцентов беспокоит.
Ну, понимаешь, библиотека PHP, например, позволяет расставить хуки так, что проблему решить удаётся, несмотря на все грабли. Ни одна из библиотек Python такие вещи не позволяет, а некоторые не работают без WSDL.
Я тоже замечал что в питоне сейчас примерно как в десктопных линуксах десять лет назад — вроде работать и можно, а чего-то всегда не хватает. То в перманентной стадии глубокой беты, то отсутствует по идеологическим соображениям.
Но вообще Иван в чём-то прав: если какой-то непонятной фигни нет в питоне, то стоит задуматься — а нужна ли она вообще? (-:
Интересная ситуация: вместо того, чтобы создавать конкурентоспособные продукты, конкуренты MS неистово реализуют поддержку новых технологий от MS. Может MS их для того и разрабатывает, чтобы занять чем-нибудь конкурентов. Вместо того, чтобы сделать нормальную альтернативу Exchange, сообщество пишет поддержку Exchange для всего подряд.
Я думаю, конкретно твой случай кончится вот чем: ты поругаешься некоторое время, а потом напишешь поддержку всего перечисленного, которая будет работать конкретно в твоих условиях, и в мире появится ещё одна библиотека на эту тему, которая не доведена до ума. Существующие библиотеки так и появились, однозначно. Никто из тех, кому такая задача по силам, не будет тратить время на написание полной, универсальной и надёжной Python-библиотеки для поддержки Exchange.
Нет, SOAP это технология от Microsoft :-). Они продавили её в качестве рекомендации W3C в своё время, но придумали её там.
А почему ты считаешь, что SOAP специально спроектирован только для маркетинговых задач?
Я не говорил «только». Хотя по сути всё правильно. Думаю я так по результатам разрозненных наблюдений за косвенными признаками (а прямых и не может быть). SOAP переусложнён, причём, похоже, что искуственно, явно не предполагает работу без сложной библиотеки (вот ссылочка в тему: http://www.xml.com/pub/a/2003/09/24/dive.html%29. Его концепция периодически пересматривалась без особой оглядки на обратную совместимость.
Вообще, сложно в рамках комментария на такие философские темы говорить :-). Я для себя все эти выводы давно сделал, трудно формулировать то, что считаешь очевидным :-).
Даже если предположить, что SOAP не от MS (хотя это и не так), то это ничего не меняет. HTTPS — точно не от MS :) Питоновские же SOAP-библиотекихудо-бедно поддерживают SOAP. В твоей проблеме ключевыми пунктами являются NTLM и WSDL-от-Excahnge 2007.
Обрати внимание, что в ряде стандартных методов для RPC (таких как XML-RPS и JSON-RPC) не предполагается использования длинного стека запутанных технологий. То, что в Excahnge нельзя влезть просто и бесхитростно — чья это вина? Питоновцев?
WDSL не может быть корнем проблемы, он по стандарту сделан. То, что библиотеки SOAP Пайтона не могут его разобрать — их вина. NTLM — проблема, да. Но тут она самая легкопобеждаемая сторонними средствами. Например, можно поставить прокси, который будет авторизовывать, а дальше отдавать просто HTTPS.
То, что в Excahnge нельзя влезть просто и бесхитростно — чья это вина? Питоновцев?
Предполагается, что SOAP и есть «просто и бесхитростно». Так оно и есть, например, из Perl это выглядит очень просто и бесхитростно: указываешь URL WDSL и просто вызываешь методы, всё дальше помимо тебя происходит.
Предполагается, что SOAP и есть «просто и бесхитростно».
Я имел в виду на уровне разработки. Когда есть отлаженная обёртка, так даже Word-doc будет простым и бесхитростным, но есть разница в простоте при реализации SOAP и обычного RPC.
Конечно, было бы замечательно, если бы Python уже мог весь твой стек до Excahnge включительно, но кто будет это писать? Опенсорсники Excahnge не любят. В мире Python вообще не так уж часто пользуются Excahnge, а если и пользуются, то корпоративные программеры, которым некогда заботиться о нуждах сообщества, им свою задачу решить надо. В общем, мой прогноз: будет теперь ещё одной неполной Python-SOAP-библиотекой больше.
Я немного не в контест а рядом. По долгу службы возникла необходимость интеграции .NET Web services (не exchange, а внутреннего корпоративного сервиса) с питоновским приложением, мне в этом хорошо помогла библиотека suds — https://fedorahosted.org/suds/ По завершению работы над проектом глюков в обмене данных python-app — .net web service замечено не было. Работал с версией из HEAD транка.
Комментарии 24
P.S. Я знаю, что тебе надо практическую задачу решить. Но меня смещение акцентов беспокоит.
Но вообще Иван в
Я думаю, конкретно твой случай кончится вот чем: ты поругаешься некоторое время, а потом напишешь поддержку всего перечисленного, которая будет работать конкретно в твоих условиях, и в мире появится ещё одна библиотека на эту тему, которая не доведена до ума. Существующие библиотеки так и появились, однозначно. Никто из тех, кому такая задача по силам, не будет тратить время на написание полной, универсальной и надёжной
Нет, SOAP это технология от Microsoft:-). Они продавили её в качестве рекомендации W3C в своё время, но придумали её там.
Я не говорил «только». Хотя по сути всё правильно. Думаю я так по результатам разрозненных наблюдений за косвенными признаками (а прямых и не может быть). SOAP переусложнён, причём, похоже, что искуственно, явно не предполагает работу без сложной библиотеки (вот ссылочка в тему: http://www.xml.com/pub/a/2003/09/24/dive.html%29. Его концепция периодически пересматривалась без особой оглядки на обратную совместимость.
:-). Я для себя все эти выводы давно сделал, трудно формулировать то, что считаешь очевидным :-).
Вообще, сложно в рамках комментария на такие философские темы говорить
Даже если предположить, что SOAP не от MS (хотя это и не так), то это ничего не меняет. HTTPS — точно не от MS :) Питоновские же
Обрати внимание, что в ряде стандартных методов для RPC (таких как
Да, понятно. Может
WDSL не может быть корнем проблемы, он по стандарту сделан. То, что библиотеки SOAP Пайтона не могут его разобрать — их вина. NTLM — проблема, да. Но тут она самая легкопобеждаемая сторонними средствами. Например, можно поставить прокси, который будет авторизовывать, а дальше отдавать просто HTTPS.
Комментарий для astur.net.ru:
Предполагается, что SOAP и есть «просто и бесхитростно». Так оно и есть, например, из Perl это выглядит очень просто и бесхитростно: указываешь URL WDSL и просто вызываешь методы, всё дальше помимо тебя происходит.
а в остальном поддерживаю мнение Ивана
Комментарий для Евгения Степанищева:
Я имел в виду на уровне разработки. Когда есть отлаженная обёртка, так дажеWord-doc будет простым и бесхитростным, но есть разница в простоте при реализации SOAP и обычного RPC.
Python-SOAP-библиотекой больше.
Конечно, было бы замечательно, если бы Python уже мог весь твой стек до Excahnge включительно, но кто будет это писать? Опенсорсники Excahnge не любят. В мире Python вообще не так уж часто пользуются Excahnge, а если и пользуются, то корпоративные программеры, которым некогда заботиться о нуждах сообщества, им свою задачу решить надо. В общем, мой прогноз: будет теперь ещё одной неполной
Да нет, причём тут