Пишу, по большей части, про историю, свою жизнь и немного про программирование.
Такой молодой Python
Девятнадцать лет языку, а модуля для него, который поддерживал бы сочетание SOAP+NTLM+HTTPS+WSDL-от-Excahnge 2007 так и нет. Ни одна из SOAP библиотек для Python не умеет это всё сразу. И большинство из них даже не смогли разобрать (полностью валидный) WSDL SOAP Exchange 2007!
Вот удивительно... Есть дико переусложнённый стек технологий, которые несовместимо меняются чуть не каждый год, и которые были *специально спроектированы* не для решения проблем, а для продажи инструментов по их обслуживанию. И теперь то, что в Питоне нет адекватных средств для работы с этой кучей хлама -- это проблема Питона?
P.S. Я знаю, что тебе надо практическую задачу решить. Но меня смещение акцентов беспокоит.
gaius-julius.livejournal.com
2009
Я тоже замечал что в питоне сейчас примерно как в десктопных линуксах десять лет назад — вроде работать и можно, а чего-то всегда не хватает. То в перманентной стадии глубокой беты, то отсутствует по идеологическим соображениям.
Но вообще Иван в чём-то прав: если какой-то непонятной фигни нет в питоне, то стоит задуматься — а нужна ли она вообще? (-:
astur (astur.net.ru)
2009
Интересная ситуация: вместо того, чтобы создавать конкурентоспособные продукты, конкуренты MS неистово реализуют поддержку новых технологий от MS. Может MS их для того и разрабатывает, чтобы занять чем-нибудь конкурентов. Вместо того, чтобы сделать нормальную альтернативу Exchange, сообщество пишет поддержку Exchange для всего подряд.
Я думаю, конкретно твой случай кончится вот чем: ты поругаешься некоторое время, а потом напишешь поддержку всего перечисленного, которая будет работать конкретно в твоих условиях, и в мире появится ещё одна библиотека на эту тему, которая не доведена до ума. Существующие библиотеки так и появились, однозначно. Никто из тех, кому такая задача по силам, не будет тратить время на написание полной, универсальной и надёжной Python-библиотеки для поддержки Exchange.
Евгений Степанищев (bolknote.ru)
2009
Комментарий для softwaremaniacs.org/about/:
Ну, понимаешь, библиотека PHP, например, позволяет расставить хуки так, что проблему решить удаётся, несмотря на все грабли. Ни одна из библиотек Python такие вещи не позволяет, а некоторые не работают без WSDL.
Евгений Степанищев (bolknote.ru)
2009
Комментарий для astur.net.ru:
SOAP не технология от Microsoft, это стандартизированный метод для RPC (Remote Procedure Call).
Евгений Степанищев (bolknote.ru)
2009
Комментарий для softwaremaniacs.org/about/:
А почему ты считаешь, что SOAP специально спроектирован только для маркетинговых задач?
Евгений Степанищев (bolknote.ru)
2009
Комментарий для gaius-julius.livejournal.com:
SOAP это не какая-то непонятная фигня :)
Евгений Степанищев (bolknote.ru)
2009
Комментарий для softwaremaniacs.org/about/:
Я подредактировал пост и постарался сместить акцент к модулю.
isagalaev (softwaremaniacs.org/about/)
2009
SOAP не технология от Microsoft
Нет, SOAP это технология от Microsoft :-). Они продавили её в качестве рекомендации W3C в своё время, но придумали её там.
А почему ты считаешь, что SOAP специально спроектирован только для маркетинговых задач?
Я не говорил «только». Хотя по сути всё правильно. Думаю я так по результатам разрозненных наблюдений за косвенными признаками (а прямых и не может быть). SOAP переусложнён, причём, похоже, что искуственно, явно не предполагает работу без сложной библиотеки (вот ссылочка в тему: http://www.xml.com/pub/a/2003/09/24/dive.html%29. Его концепция периодически пересматривалась без особой оглядки на обратную совместимость.
Вообще, сложно в рамках комментария на такие философские темы говорить :-). Я для себя все эти выводы давно сделал, трудно формулировать то, что считаешь очевидным :-).
astur (astur.net.ru)
2009
Комментарий для Евгения Степанищева:
Даже если предположить, что SOAP не от MS (хотя это и не так), то это ничего не меняет. HTTPS — точно не от MS :) Питоновские же SOAP-библиотеки худо-бедно поддерживают SOAP. В твоей проблеме ключевыми пунктами являются NTLM и WSDL-от-Excahnge 2007.
Обрати внимание, что в ряде стандартных методов для RPC (таких как XML-RPS и JSON-RPC) не предполагается использования длинного стека запутанных технологий. То, что в Excahnge нельзя влезть просто и бесхитростно — чья это вина? Питоновцев?
Евгений Степанищев (bolknote.ru)
2009
Комментарий для softwaremaniacs.org/about/:
Да, понятно. Может как-нибудь расскажешь мне это за чаем, если сможешь всё-таки сформулировать :)
Евгений Степанищев (bolknote.ru)
2009
Комментарий для astur.net.ru:
WDSL не может быть корнем проблемы, он по стандарту сделан. То, что библиотеки SOAP Пайтона не могут его разобрать — их вина. NTLM — проблема, да. Но тут она самая легкопобеждаемая сторонними средствами. Например, можно поставить прокси, который будет авторизовывать, а дальше отдавать просто HTTPS.
Евгений Степанищев (bolknote.ru)
2009
Комментарий для astur.net.ru:
То, что в Excahnge нельзя влезть просто и бесхитростно — чья это вина? Питоновцев?
Предполагается, что SOAP и есть «просто и бесхитростно». Так оно и есть, например, из Perl это выглядит очень просто и бесхитростно: указываешь URL WDSL и просто вызываешь методы, всё дальше помимо тебя происходит.
lordsc (lordsc.myopenid.com)
2009
ntlm вообще устаревшая какашка )
а в остальном поддерживаю мнение Ивана
Евгений Степанищев (bolknote.ru)
2009
Комментарий для lordsc.myopenid.com:
А что более новая, надёжная какашка?
astur (astur.net.ru)
2009
Комментарий для Евгения Степанищева:
Предполагается, что SOAP и есть «просто и бесхитростно».
Я имел в виду на уровне разработки. Когда есть отлаженная обёртка, так даже Word-doc будет простым и бесхитростным, но есть разница в простоте при реализации SOAP и обычного RPC.
Конечно, было бы замечательно, если бы Python уже мог весь твой стек до Excahnge включительно, но кто будет это писать? Опенсорсники Excahnge не любят. В мире Python вообще не так уж часто пользуются Excahnge, а если и пользуются, то корпоративные программеры, которым некогда заботиться о нуждах сообщества, им свою задачу решить надо. В общем, мой прогноз: будет теперь ещё одной неполной Python-SOAP-библиотекой больше.
windock.livejournal.com
2009
В .NET должна быть поддержка всего этого. Так что может помочь IronPython.
Евгений Степанищев (bolknote.ru)
2009
Комментарий для astur.net.ru:
Да нет, причём тут Exchange-то? Exchange использует вполне себе стандартный SOAP, просто под Python нет реализации этого самого стандартного.
Евгений Степанищев (bolknote.ru)
2009
Комментарий для windock.livejournal.com:
Нам ещё этого не хватало к нашему зоопарку :) Лучше написать какой-нить прокси Exchange SOAP ↔ PHP или Perl ↔ socket ↔ Python.
nimnull.blogspot.com
2009
Я немного не в контест а рядом. По долгу службы возникла необходимость интеграции .NET Web services (не exchange, а внутреннего корпоративного сервиса) с питоновским приложением, мне в этом хорошо помогла библиотека suds — https://fedorahosted.org/suds/ По завершению работы над проектом глюков в обмене данных python-app — .net web service замечено не было. Работал с версией из HEAD транка.
Евгений Степанищев (bolknote.ru)
2009
Комментарий для nimnull.blogspot.com:
Спасибо! Попробуем посмотреть!
Евгений Степанищев (bolknote.ru)
2009
Комментарий для nimnull.blogspot.com:
Название что-то уж очень знакомое, может и смотрели, завтра гляну.
Антон
2011
Прошло два года, а ситуация не поменялась в лучшую сторону. suds тоже не понятно поддерживает кто-то или нет.
Евгений Степанищев (bolknote.ru)
2011
Комментарий для Антон:
У suds всё плохо, но есть несколько форков, в них можно покопаться.
Вот удивительно... Есть дико переусложнённый стек технологий, которые несовместимо меняются чуть не каждый год, и которые были *специально спроектированы* не для решения проблем, а для продажи инструментов по их обслуживанию. И теперь то, что в Питоне нет адекватных средств для работы с этой кучей хлама -- это проблема Питона?
P.S. Я знаю, что тебе надо практическую задачу решить. Но меня смещение акцентов беспокоит.
Я тоже замечал что в питоне сейчас примерно как в десктопных линуксах десять лет назад — вроде работать и можно, а чего-то всегда не хватает. То в перманентной стадии глубокой беты, то отсутствует по идеологическим соображениям.
Но вообще Иван в чём-то прав: если какой-то непонятной фигни нет в питоне, то стоит задуматься — а нужна ли она вообще? (-:
Интересная ситуация: вместо того, чтобы создавать конкурентоспособные продукты, конкуренты MS неистово реализуют поддержку новых технологий от MS. Может MS их для того и разрабатывает, чтобы занять чем-нибудь конкурентов. Вместо того, чтобы сделать нормальную альтернативу Exchange, сообщество пишет поддержку Exchange для всего подряд.
Я думаю, конкретно твой случай кончится вот чем: ты поругаешься некоторое время, а потом напишешь поддержку всего перечисленного, которая будет работать конкретно в твоих условиях, и в мире появится ещё одна библиотека на эту тему, которая не доведена до ума. Существующие библиотеки так и появились, однозначно. Никто из тех, кому такая задача по силам, не будет тратить время на написание полной, универсальной и надёжной Python-библиотеки для поддержки Exchange.
Комментарий для softwaremaniacs.org/about/:
Ну, понимаешь, библиотека PHP, например, позволяет расставить хуки так, что проблему решить удаётся, несмотря на все грабли. Ни одна из библиотек Python такие вещи не позволяет, а некоторые не работают без WSDL.
Комментарий для astur.net.ru:
SOAP не технология от Microsoft, это стандартизированный метод для RPC (Remote Procedure Call).
Комментарий для softwaremaniacs.org/about/:
А почему ты считаешь, что SOAP специально спроектирован только для маркетинговых задач?
Комментарий для gaius-julius.livejournal.com:
SOAP это не какая-то непонятная фигня :)
Комментарий для softwaremaniacs.org/about/:
Я подредактировал пост и постарался сместить акцент к модулю.
Нет, SOAP это технология от Microsoft :-). Они продавили её в качестве рекомендации W3C в своё время, но придумали её там.
Я не говорил «только». Хотя по сути всё правильно. Думаю я так по результатам разрозненных наблюдений за косвенными признаками (а прямых и не может быть). 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 нельзя влезть просто и бесхитростно — чья это вина? Питоновцев?
Комментарий для softwaremaniacs.org/about/:
Да, понятно. Может как-нибудь расскажешь мне это за чаем, если сможешь всё-таки сформулировать :)
Комментарий для astur.net.ru:
WDSL не может быть корнем проблемы, он по стандарту сделан. То, что библиотеки SOAP Пайтона не могут его разобрать — их вина. NTLM — проблема, да. Но тут она самая легкопобеждаемая сторонними средствами. Например, можно поставить прокси, который будет авторизовывать, а дальше отдавать просто HTTPS.
Комментарий для astur.net.ru:
Предполагается, что SOAP и есть «просто и бесхитростно». Так оно и есть, например, из Perl это выглядит очень просто и бесхитростно: указываешь URL WDSL и просто вызываешь методы, всё дальше помимо тебя происходит.
ntlm вообще устаревшая какашка )
а в остальном поддерживаю мнение Ивана
Комментарий для lordsc.myopenid.com:
А что более новая, надёжная какашка?
Комментарий для Евгения Степанищева:
Я имел в виду на уровне разработки. Когда есть отлаженная обёртка, так даже Word-doc будет простым и бесхитростным, но есть разница в простоте при реализации SOAP и обычного RPC.
Конечно, было бы замечательно, если бы Python уже мог весь твой стек до Excahnge включительно, но кто будет это писать? Опенсорсники Excahnge не любят. В мире Python вообще не так уж часто пользуются Excahnge, а если и пользуются, то корпоративные программеры, которым некогда заботиться о нуждах сообщества, им свою задачу решить надо. В общем, мой прогноз: будет теперь ещё одной неполной Python-SOAP-библиотекой больше.
В .NET должна быть поддержка всего этого. Так что может помочь IronPython.
Комментарий для astur.net.ru:
Да нет, причём тут Exchange-то? Exchange использует вполне себе стандартный SOAP, просто под Python нет реализации этого самого стандартного.
Комментарий для windock.livejournal.com:
Нам ещё этого не хватало к нашему зоопарку :) Лучше написать какой-нить прокси Exchange SOAP ↔ PHP или Perl ↔ socket ↔ Python.
Я немного не в контест а рядом. По долгу службы возникла необходимость интеграции .NET Web services (не exchange, а внутреннего корпоративного сервиса) с питоновским приложением, мне в этом хорошо помогла библиотека suds — https://fedorahosted.org/suds/ По завершению работы над проектом глюков в обмене данных python-app — .net web service замечено не было. Работал с версией из HEAD транка.
Комментарий для nimnull.blogspot.com:
Спасибо! Попробуем посмотреть!
Комментарий для nimnull.blogspot.com:
Название что-то уж очень знакомое, может и смотрели, завтра гляну.
Прошло два года, а ситуация не поменялась в лучшую сторону. suds тоже не понятно поддерживает кто-то или нет.
Комментарий для Антон:
У suds всё плохо, но есть несколько форков, в них можно покопаться.