Такой молодой Python

Девятнадцать лет языку, а модуля для него, который поддерживал бы сочетание SOAP+NTLM+HTTPS+WSDL-от-Excahnge 2007 так и нет. Ни одна из SOAP библиотек для Python не умеет это всё сразу. И большинство из них даже не смогли разобрать (полностью валидный) WSDL SOAP Exchange 2007!

Читайте также

«Переговорки»: панихида
Проект «Переговорки» — внутренний веб-сервис «Яндекса» для бронирования переговорок, синхронизированный с Microsoft Exchange. Это, наверное, самый сложный проект, который мне приходилось делать за всю жизнь.
2009

Комментарии 24

isagalaev (softwaremaniacs.org/about/) № 1
Вот удивительно… Есть дико переусложнённый стек технологий, которые несовместимо меняются чуть не каждый год, и которые были *специально спроектированы* не для решения проблем, а для продажи инструментов по их обслуживанию. И теперь то, что в Питоне нет адекватных средств для работы с этой кучей хлама -- это проблема Питона?

P.S. Я знаю, что тебе надо практическую задачу решить. Но меня смещение акцентов беспокоит.
Евгений Степанищев (bolknote.ru) автор № 4
Ну, понимаешь, библиотека PHP, например, позволяет расставить хуки так, что проблему решить удаётся, несмотря на все грабли. Ни одна из библиотек Python такие вещи не позволяет, а некоторые не работают без WSDL.
gaius-julius.livejournal.com № 2
Я тоже замечал что в питоне сейчас примерно как в десктопных линуксах десять лет назад — вроде работать и можно, а чего-то всегда не хватает. То в перманентной стадии глубокой беты, то отсутствует по идеологическим соображениям.

Но вообще Иван в чём-то прав: если какой-то непонятной фигни нет в питоне, то стоит задуматься — а нужна ли она вообще? (-:
astur (astur.net.ru) № 3
Интересная ситуация: вместо того, чтобы создавать конкурентоспособные продукты, конкуренты MS неистово реализуют поддержку новых технологий от MS. Может MS их для того и разрабатывает, чтобы занять чем-нибудь конкурентов. Вместо того, чтобы сделать нормальную альтернативу Exchange, сообщество пишет поддержку Exchange для всего подряд.

Я думаю, конкретно твой случай кончится вот чем: ты поругаешься некоторое время, а потом напишешь поддержку всего перечисленного, которая будет работать конкретно в твоих условиях, и в мире появится ещё одна библиотека на эту тему, которая не доведена до ума. Существующие библиотеки так и появились, однозначно. Никто из тех, кому такая задача по силам, не будет тратить время на написание полной, универсальной и надёжной Python-библиотеки для поддержки Exchange.
isagalaev (softwaremaniacs.org/about/) № 9
SOAP не технология от Microsoft

Нет, SOAP это технология от Microsoft :-). Они продавили её в качестве рекомендации W3C в своё время, но придумали её там.

А почему ты считаешь, что SOAP специально спроектирован только для маркетинговых задач?

Я не говорил «только». Хотя по сути всё правильно. Думаю я так по результатам разрозненных наблюдений за косвенными признаками (а прямых и не может быть). SOAP переусложнён, причём, похоже, что искуственно, явно не предполагает работу без сложной библиотеки (вот ссылочка в тему: http://www.xml.com/pub/a/2003/09/24/dive.html%29. Его концепция периодически пересматривалась без особой оглядки на обратную совместимость.

Вообще, сложно в рамках комментария на такие философские темы говорить :-). Я для себя все эти выводы давно сделал, трудно формулировать то, что считаешь очевидным :-).

astur (astur.net.ru) № 10
Комментарий для Евгения Степанищева:

Даже если предположить, что SOAP не от MS (хотя это и не так), то это ничего не меняет. HTTPS — точно не от MS :) Питоновские же SOAP-библиотеки худо-бедно поддерживают SOAP. В твоей проблеме ключевыми пунктами являются NTLM и WSDL-от-Excahnge 2007.

Обрати внимание, что в ряде стандартных методов для RPC (таких как XML-RPS и JSON-RPC) не предполагается использования длинного стека запутанных технологий. То, что в Excahnge нельзя влезть просто и бесхитростно — чья это вина? Питоновцев?
Евгений Степанищев (bolknote.ru) автор № 11
Комментарий для softwaremaniacs.org/about/:

Да, понятно. Может как-нибудь расскажешь мне это за чаем, если сможешь всё-таки сформулировать :)
Евгений Степанищев (bolknote.ru) автор № 12
Комментарий для astur.net.ru:

WDSL не может быть корнем проблемы, он по стандарту сделан. То, что библиотеки SOAP Пайтона не могут его разобрать — их вина. NTLM — проблема, да. Но тут она самая легкопобеждаемая сторонними средствами. Например, можно поставить прокси, который будет авторизовывать, а дальше отдавать просто HTTPS.
Евгений Степанищев (bolknote.ru) автор № 13

Комментарий для astur.net.ru:

То, что в Excahnge нельзя влезть просто и бесхитростно — чья это вина? Питоновцев?

Предполагается, что SOAP и есть «просто и бесхитростно». Так оно и есть, например, из Perl это выглядит очень просто и бесхитростно: указываешь URL WDSL и просто вызываешь методы, всё дальше помимо тебя происходит.

astur (astur.net.ru) № 16

Комментарий для Евгения Степанищева:

Предполагается, что SOAP и есть «просто и бесхитростно».

Я имел в виду на уровне разработки. Когда есть отлаженная обёртка, так даже Word-doc будет простым и бесхитростным, но есть разница в простоте при реализации SOAP и обычного RPC.

Конечно, было бы замечательно, если бы Python уже мог весь твой стек до Excahnge включительно, но кто будет это писать? Опенсорсники Excahnge не любят. В мире Python вообще не так уж часто пользуются Excahnge, а если и пользуются, то корпоративные программеры, которым некогда заботиться о нуждах сообщества, им свою задачу решить надо. В общем, мой прогноз: будет теперь ещё одной неполной Python-SOAP-библиотекой больше.

windock.livejournal.com № 17
В .NET должна быть поддержка всего этого. Так что может помочь IronPython.
Евгений Степанищев (bolknote.ru) автор № 19
Нам ещё этого не хватало к нашему зоопарку :) Лучше написать какой-нить прокси Exchange SOAP ↔ PHP или Perl ↔ socket ↔ Python.
Евгений Степанищев (bolknote.ru) автор № 18
Комментарий для astur.net.ru:

Да нет, причём тут Exchange-то? Exchange использует вполне себе стандартный SOAP, просто под Python нет реализации этого самого стандартного.
nimnull.blogspot.com № 20
Я немного не в контест а рядом. По долгу службы возникла необходимость интеграции .NET Web services (не exchange, а внутреннего корпоративного сервиса) с питоновским приложением, мне в этом хорошо помогла библиотека suds — https://fedorahosted.org/suds/ По завершению работы над проектом глюков в обмене данных python-app — .net web service замечено не было. Работал с версией из HEAD транка.
Антон № 23
Прошло два года, а ситуация не поменялась в лучшую сторону. suds тоже не понятно поддерживает кто-то или нет.