Каковы плюсы и минусы PyRo и RPyC библиотек python?

Question

Я ищу механизм удаленного вызова процедур для Python, и я нашел это PyRo (Удаленный объект Python) и RPyC (Удаленный вызов Python) и то, и другое - это то, что я ищу.

Тем не менее, мне любопытно узнать, как они соотносятся друг с другом и каковы их плюсы и минусы?

Answer 1

Лично я нахожу их примерно эквивалентными, но автор RPyC ( здесь ) требует большей простоты (и, возможно, для у кого-то не все, кто привык к распределенным вычислениям, у него есть точка зрения, я, возможно, слишком привык к этому, чтобы составить хорошее мнение ;-). Цитирую его ...:

  

хотя PYRO имеет длинный список   значительные проекты в своем резюме, я   найти настройку сервера тоже   сложный, если принять во внимание   количество необходимого кода, регистрация   объекты, работающие серверы имен и т. д.   Не говоря уже о количестве разных   концепции, которые вы должны рассмотреть (события,   переплет, с именем или без   серверы, прокси против атрибута-прокси,   имена должны быть уникальными и т. д.). А также   это ограничено (удаленные объекты должны быть   мариновать, чтобы вы не могли работать с   удаленные файлы и т. д.). В общем, пиро   имеет слишком много особых случаев и   как правило, слишком сложно (да, я   считаю это сложным). Так что из   Конечно, я не независимый рецензент   - но судите сами. Разве RPyC не проще и чище?

С другой стороны, PyRO пытается обеспечить некоторую безопасность (что, по мнению автора RPyC, в любом случае слишком слабо и лежит в основе многих заявленных сложностей PyRO).

Более независимый голос, Дэвид Мерц, предлагает здесь хорошее объяснение RPyC (PyRO существует намного дольше, и Дэвид указывает на предыдущие статьи, посвященные этому). «Классический режим» является полностью общей и простой частью с нулевой безопасностью, "по существу идентичной Pyro (без дополнительной структуры безопасности Pyro)"; «режим услуг»; более безопасен (все, что явно не разрешено, по умолчанию запрещено) и, по словам Дэвида, " сервисный режим по существу является RPC (например, XML_RPC), по модулю некоторых деталей относительно соглашений о вызовах и их реализации ». Мне кажется, это справедливая оценка.

Кстати, мне не особенно нравятся одноязычные RPC-системы - даже если Python покрывает 99% моих потребностей (и это не совсем так ;-), мне нравится тот факт, что я могу использовать любой язык для оставшиеся 1% ... Я не хочу отказываться от этого на уровне RPC! -) Я бы лучше сделал, например, JSON-RPC через этот модуль или что-то подобное ...! -).

Answer 2

YMMV, но вот мои результаты оценки RPyC, Pyro4 и ZeroRPC для использования в предстоящем проекте.Обратите внимание, что здесь нет подробных тестов, и это не задумано как подробный обзор, просто мои заметки о том, насколько хорошо каждый из них подходит для нужд моего предстоящего проекта.

ZeroRPC:

• довольно много зависимостей
• очень молодой проект (основная поддержка со стороны dotCloud)
• очень мало документации
• не могу получить доступ к атрибутам удаленного объекта, только к методам
• Из-за отсутствия доступа к атрибутам завершение вкладки IPython не работает на удаленных объектах

Пиро4:

• Поддержка Python3
• Хорошая, обильная документация
• зрелый проект
• Нет доступа к атрибуту / Завершение вкладки IPython

Пиро3:

• поддержка доступа к атрибутам (заявлена в документах;не проверяли)
• Нет поддержки Python3

RPyC:

• доступ к атрибутам, завершение работы с вкладкой IPython на удаленных объектах
• Поддержка Python3 (заявлена в документах;еще не проверено)
• неоднородная документация

FWIW:

Мне, как правило, нравится RPyC (может быть, потому, что это был мой первый?;-), но документация по нему скудная.Это было мое первое знакомство с RPC, и мне потребовалось много времени, чтобы "понять", как заставить все работать.Автор (Tomer) очень полезен и отвечает на вопросы из списка RPyC Google.

Если вы новичок в RPC, я бы посоветовал начать с Pyro и воспользоваться его надежной документацией, чтобы освоиться.Переходите к RPyC, ZeroRPC и т.д.в соответствии с вашими потребностями.