Re: GNUStep and Cocoa Distributed Objects compatibility

[hns]

On 22 Mrz., 20:59, Piotr Isajew <p...@ex.com.pl> wrote:
> hns pisze:
>
>
>
> > On 22 Mrz., 19:49, Richard Frith-Macdonald
> > <rich...@tiptree.demon.co.uk> wrote:
> >> On 22 Mar 2009, at 17:31, hns wrote:
>
> >>> On 22 Mrz., 12:12, Richard Frith-Macdonald
> >>> <rich...@tiptree.demon.co.uk> wrote:
> >>>> On 22 Mar 2009, at 10:23, Piotr Isajew wrote:
> >>>>> Hello
> >>>>> I would like to use Distributed Objects to communicate through the
> >>>>> network between Objective C GNU Step application (let's say running
> >>>>> on Linux) and it's Mac OS X counterpart). Does anybody have any
> >>>>> experience using DO in such configuration? Is GNUStep's DO
> >>>>> implementation compatible with Cocoa's one?
> >>>> No, the two implementations are not binary compatible, and making  
> >>>> them
> >>>> compatible would be quite a big job (though it's certainly not
> >>>> impossible ... as we have a binary compatible implementation of keyed
> >>>> coding for NIBs already, and Nikolaus Schaler has written a binary
> >>>> compatible version of NSSocketPort for mySTEP which GNUstep could
> >>>> use ... so a project to implement binary compatible DO would need to
> >>>> re-implement NSConnection and NSPortCoder to use those).
> >>>> Currently, for IPC between GNUstep and Cocoa I'd recommend using
> >>>> XMLRPC.  The GNUstep webservices library provides (as a tiny part of
> >>>> its functionality) an XMLRPC coder and invocation methods, and this
> >>>> library can be built/used either with gnustep-make (for gnustep) or
> >>>> with xcode (for cocoa).
> >>> As Richard mentioned there are 3 levels where compatibility would have
> >>> to be achieved:
> >>> 1. basic communication stream - this is the NSSocketPort
> >>> 2. starting and maintaining connections and referencing remote objects
> >>> - this is NSConnection, NSProxy and NSDistributedObject
> >>> 3. encode object's instance variables and the method name - this is
> >>> NSPortCoder which probably uses -initWIthCoder
> >>> Level 1 has an implementation in mySTEP (but not deeply tested for
> >>> real compatibility and robustness)
> >>> Level 2 is not yet compatible - but could be made with some more
> >>> analysis
> >>> Level 3 is probably impossible without turning GNUstep upside down,
> >>> since GNUstep encoding of objects is not compatible to Cocoa. There is
> >>> no documentation available and it may even be changed by Apple in
> >>> every release.
> >> A year or two back someone told me that Apple DO supported keyed  
> >> archiving for DO.
> >> If that's true, then we pretty much already have compatibility at  
> >> level 3, because we have binary compatible keyed archiving (it's used  
> >> to encode/decode NIBs).  What would be needed would be to reverse  
> >> engineer the apple stuff to be able to turn on the use of keyed coding.
>
> >>From my experiments done so far (which are difficult as long as Level
> > 2 is not working) it does not look like NSPortCoder uses keyed coding.
> > But it needs much more analysis.
>
> > To analyse you must install a forwarder process that sits in the
> > middle of a DO socket based connection and prints all bits and bytes
> > is sees.
>
> Thanks for the explaination. I'll try to set up tomorrow a DO connection
> between 2 OSX machines, put a tcpdump between and see what goes on the wire.

Well, tcpdump is not sufficient since on that level you will only see
the full NSPortMessages but the important thing is the payload.

-- hns