PyRO (Python Remote Objects)

Лучше напиши, чем это лучше omniORBpy :)

Ну знаком с PyRO. Ты спроси чего хотел-то, может и смогу ответить...

Pyro, это ерунда которая реализует RMI через сереализацию.

Работает через UDP (если не ошибаюсь).

В использовании _черезвычайно_ простая штука.

Теперь лучше ты напиши, чем это хуже чем omniORBpy :-)

предыдущие два сообщения мои :-)

> В использовании _черезвычайно_ простая штука.

Мне и omniORBpy не показался сложным :)

>Теперь лучше ты напиши, чем это хуже чем omniORBpy :-)

Проблема в том, что я не пользовался PyRO. Однако попробую догадаться - интероперабельность у него == 0 ?

my $0.02:

очень часто нужно просто оффлоадить вычисления/данные на одну соседнюю машину, в таких случаях отлаженные ad-hoc RMI системы рулят - не взгромождать же из-за такой фигни цельную корбу?

Задача состоит в реализации распределённых вычислений на компьютерах, соединённых посредством TCP/IP. Пусть есть некоторый сервер, на который подаётся задание, он должен раскидать по клиентам вызовы функций и в случае если функция не определена (в среде клиента) -- переслать код. Также есть определённый тип глобальных объектов (которе нужно хранить на сервере скорее всего) при обращении к которым, трэд, выполняющий задание на клиенте, должен приостановить выполнение, если соответствующее значение пусто.

Может ли здесь как-то помочь omniORBpy?

> в таких случаях отлаженные ad-hoc RMI системы рулят

Я не совсем понял, о чем речь, но... каждый использует то, к чему привык.

> не взгромождать же из-за такой фигни цельную корбу?

"Взгромождать"? Не вижу проблемы - ставишь пакеты, и всё.

> в таких случаях отлаженные ad-hoc RMI системы рулят

> Я не совсем понял, о чем речь, но... каждый использует то, к чему привык.

Ну, грубо говоря, если мне достаточно сделать cat datafile | ssh otherhost awk '{some program}' | perl -e 'local processing', то я не буду вместо этого ставить и настраивать омниорба и писать серванты на питоне или какой-нибудь там яве.

Но OP явно нужна целикова корба, это да.

> реализации распределённых вычислений на компьютерах, соединённых посредством TCP/IP.

> ...

> Может ли здесь как-то помочь omniORBpy?

Если бы не "в случае если функция не определена (в среде клиента) -- переслать код", я бы сказал, что CORBA для таких задач и предназначена. Но вот насчет динамической пересылки кода - не буду врать, такого никогда не делал, и даже не очень понимаю, как это решить в общем случае. Допустим, пересылается .pyc-файл, но где гарантия, что он не потребует другие .pyc-файлы или .so, которых на клиенте нет? В общем случае я бы не взялся решать такое. В ограниченном (самодостаточный .pyc-файл) - реализовать можно, но "руками", в CORBA таких возможностей нет. Впрочем, реализация прямолинейна.

CORBA - это протокол RPC + язык описания интерфейсов + bindings к языкам. Сильные стороны - богатый IDL, высокая степень интероперабельности, стандартность.

Цитатат с сайта pyro: Pyro provides an object-oriented form of RPC. You can use Pyro within a single system but also use it for IPC. For those that are familiar with Java, Pyro resembles Java's Remote Method Invocation (RMI). It is less similar to CORBA - which is a system- and language independent Distributed Object Technology and has much more to offer than Pyro or RMI. But Pyro is small, simple and free!

Не надо городить огород с IDL, просто взял обычный питоновский объект и сказад pyro его обслуживать, и всё на клиенте появляется proxy обслуживаемого объекта. Хотя ты прав, интероперабельность равна нулю.

Но для случая Python <-> Python самое то.

В Pyro код уже должен находится на клиенте. Хотя и можно попробовать заливать на клиент и py файлы. Делать импорты, реимпорты и т.д.

Но это придётся делать самому.

Посмотри на http://rpyc.wikispaces.com может оно тебе больше подойдёт.