Re: problems with Distributed Objects and PyObjC

View: New views
3 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: problems with Distributed Objects and PyObjC

by Hamish Sanderson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ronald Oussoren wrote:

> On Tuesday, October 20, 2009, at 01:20PM, "Hamish Sanderson" <hsanderson@...
> > wrote:
>> Trying to use Distributed Objects to communicate between PyObjC-based
>> processes on 10.5 and/or 10.6, but encountering various problems when
>> passing Python values, as illustrated below.
>
> Full DO support requires defining new protocols, which won't work on  
> 64-bit builds.  Even the limited DO support you need may or may not  
> work because it is a low-level library that might interfere with  
> PyObjC. I don't have unittests or sample code for this and hence  
> cannot guarantee that this will work.

Hmm. Sounds like DO isn't a good way to go in Python (and I've already  
discounted Apple events), so I suspect I'll have to look elsewhere for  
a long-term solution.


> I will look into your issues though, but not today.

OK, it isn't urgent. I'm not passing anything complex so can work  
around the problem by ensuring all Python objects are converted to  
Cocoa instances before handing them off to DO.


> An alternative to DO is to use a native Python library (Twisted, XML-
> RPC, ...) combined with Bonjour.

Will investigate these options.


Irmen de Jong wrote:

>> Anyone any thoughts? (Including suggestions for alternative LAN-
>> capable IPC options.)
>
> Both ends are Python?

Python + PyObjC.


> If they are, maybe you should try Pyro (http://pyro.sourceforge.net).

Reading the docs. A few questions, if you don't mind:

- Will Pyro play well with PyObjC objects?

- How does it compare to, say, DO+Bonjour (which is the only object-
oriented IPC system I'm vaguely familiar with)?

- And how well will it cope if some components stall or crash? (One of  
the reasons for moving to a more distributed design is that some parts  
of the system are inherently unreliable, so the rest of the system  
will need to survive if/when those processes go down, and be able to  
reconnect once they are restarted.)


Thanks,

Hamish

--

Hamish Sanderson
Production Workflow Developer
Sun Branding Solutions Ltd
Tel: +44(0)1274 200 700
www.s-brandingsolutions.com




_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: problems with Distributed Objects and PyObjC

by Irmen de Jong-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hamish Sanderson wrote:

> Reading the docs. A few questions, if you don't mind:
>
> - Will Pyro play well with PyObjC objects?

I can't say anything about this, I have zero experience with PyObjC.

> - How does it compare to, say, DO+Bonjour (which is the only
> object-oriented IPC system I'm vaguely familiar with)?

Pyro is a 100% Python remote object library and as such will be
different on a lot of aspects, I think, because it is not tied to any OS specific
technology (other than TCP/IP sockets).
Pyro is capable of handling any Python object that can be pickled.
It uses Python's native pickle format for data transfer, which makes it quite fast.
It has no auto discovery mechanism but it has a centralized object registry, which can
be discovered by other objects using a network broadcast.

For more information please read the documentation.

> - And how well will it cope if some components stall or crash? (One of
> the reasons for moving to a more distributed design is that some parts
> of the system are inherently unreliable, so the rest of the system will
> need to survive if/when those processes go down, and be able to
> reconnect once they are restarted.)

Pyro's got some basic features to deal with lost connections (due to component crash or
network problems etc). By adding a few lines to your code you can detect a broken
connection and try to reconnect the object to its target.
You can also deal with message transfer timeouts in a basic way.

If you want truly reliable message transfer or transactional behavior across objects,
Pyro is probably not the right choice.

-irmen

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: problems with Distributed Objects and PyObjC

by Ronald Oussoren :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 24 Oct, 2009, at 15:23, Irmen de Jong wrote:

> Hamish Sanderson wrote:
>
>> Reading the docs. A few questions, if you don't mind:
>> - Will Pyro play well with PyObjC objects?
>
> I can't say anything about this, I have zero experience with PyObjC.
>
>> - How does it compare to, say, DO+Bonjour (which is the only object-oriented IPC system I'm vaguely familiar with)?
>
> Pyro is a 100% Python remote object library and as such will be
> different on a lot of aspects, I think, because it is not tied to any OS specific technology (other than TCP/IP sockets).
> Pyro is capable of handling any Python object that can be pickled.
> It uses Python's native pickle format for data transfer, which makes it quite fast.
> It has no auto discovery mechanism but it has a centralized object registry, which can be discovered by other objects using a network broadcast.
If it Pyro pickles objects for transmission it should work with PyObjC objects, but only if the programmer writes custom __reduce__ methods. PyObjC objects are not pickleable by default, because I haven't found a way yet to translate the native Cocoa serialization support (NSCoding) into Python's pickle mechansim.

Adding bonjour support on top of Pyro should then be easy enough: just use Cocoa's support classes for that.

Ronald

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@...
http://mail.python.org/mailman/listinfo/pythonmac-sig

smime.p7s (4K) Download Attachment