DO question
-
Hey Folks,
Is possible to run DO connection between MacOSX and MacOSXS?
I have trouble doing it, and I'm wondering if I'm doing something wrong, or they just do not like to talk to each other...
Thanks
gt
Georg Tuparev <gtupar...>
ObjectZoo Ltd.
Titiaanstraat 13 3 Cathles Road
1077 RC Amsterdam, The Netherlands London SW12 9LE, UK
Mobile: +31-655-798196 Fax: +31-20-524-1254 -
On Wednesday, December 27, 2000, at 05:48 AM, Georg Tuparev wrote:> Is possible to run DO connection between MacOSX and MacOSXS?
In theory, yes. Not "out of the box", however.
The default transport mechanism that DO used in Mac OS X Server is not
available in Mac OS X, and thus can't communicate to Mac OS X machines.
The default mechanism used in Mac OS X is an intra-machine mechanism
only, and thus can't communicate with other machines. The conclusion is
that you can do this, if you write your own DO transport layer. Some
features, such as named lookup of objects, aren't available unless you
write a name server (NSPortNameServer subclass) to go with your new
transport, and use it. The most basic description of a DO transport is
that it has to be able to package up NSDatas and NSPorts (a subclass of
the latter, which represents your particular transport) and ship it to
the other end, which has to unpack it and then give the info to DO. You
make NSConnections using ports which are instances of your subclass,
then use DO as usual. The TCPPort example in Mac OS X Server is an
example of doing DO over BSD sockets, for instance. Some minor feature
additions have been made and classes added to DO in Mac OS X to factor
responsibilities a bit better and make writing your own transport
somewhat simpler, but these aren't available to Mac OS X Server (1.2 or
less), of course.
Another thing that impacts cross-OS-version DO is the archiving
format/version of classes. I don't think any of the basic Foundation
classes have changed this since Mac OS X Server, so I don't think there
would be any problem there.
Chris Kane
Cocoa Frameworks, Apple, Inc. -
On Wednesday, December 27, 2000, at 08:39 PM, Chris Kane wrote:> On Wednesday, December 27, 2000, at 05:48 AM, Georg Tuparev wrote:
>> Is possible to run DO connection between MacOSX and MacOSXS?
>
> In theory, yes. Not "out of the box", however.
>
> The default transport mechanism that DO used in Mac OS X Server is not
> available in Mac OS X, and thus can't communicate to Mac OS X machines.
> The default mechanism used in Mac OS X is an intra-machine mechanism
> only, and thus can't communicate with other machines.
I suppose it is unlikely that you can say but why was this made intra-machine only be default?
If someone writes this, it would be great to get the source out there... or document how to do it on Stepwise.. ;-) -
On Thursday, December 28, 2000, at 01:10 AM, Scott Anguish wrote:> On Wednesday, December 27, 2000, at 08:39 PM, Chris Kane wrote:
>> On Wednesday, December 27, 2000, at 05:48 AM, Georg Tuparev wrote:
>>> Is possible to run DO connection between MacOSX and MacOSXS?
>> In theory, yes. Not "out of the box", however.
>>
>> The default transport mechanism that DO used in Mac OS X Server is not
>> available in Mac OS X, and thus can't communicate to Mac OS X machines.
>> The default mechanism used in Mac OS X is an intra-machine mechanism
>> only, and thus can't communicate with other machines.
>
> I suppose it is unlikely that you can say but why was this made intra-machine only be
> default?
I believe Apple removed the nmserver functionality (wrt. the older Mach kernel). The old DO transport is dependent on Mach messaging (thus the machd in OPENSTEP/Enterprise). The nmserver was responsible for sending Mach messages between machines. Without the nmserver, there is no inter-machine Mach messaging. So you have to implement another transport layer. It's just as well, because the old nmserver was quite buggy and unstable - it worked enough for demos and simple demands, but failed in every deployment I've used it in. :-( It works better on x86 than on SPARC.
Quite honestly, DO is really cool technology until one actually wants to use it. Then the luster quickly drops off and you will realize you have should just developed a standard interface in the first place.
..Bill Chin
M Dimension Technology -
General Warning: some bare truths follow. Some people get upset by
truth. If you are one of them, stop reading and delete this message now.
On Wednesday, December 27, 2000, at 10:10 PM, Scott Anguish wrote:> On Wednesday, December 27, 2000, at 08:39 PM, Chris Kane wrote:
>> On Wednesday, December 27, 2000, at 05:48 AM, Georg Tuparev wrote:
>>> Is possible to run DO connection between MacOSX and MacOSXS?
>>
>> In theory, yes. Not "out of the box", however.
>>
>> The default transport mechanism that DO used in Mac OS X Server is not
>> available in Mac OS X, and thus can't communicate to Mac OS X machines.
>> The default mechanism used in Mac OS X is an intra-machine mechanism
>> only, and thus can't communicate with other machines.
>
> I suppose it is unlikely that you can say but why was this made
> intra-machine only be default?
Primarily this was the result of elimination of the old nmserver from
the product.
There were several factors:
* Mach 3.0. The new Mach brought with it a changed IPC message
structure ("untyped IPC"). Aspects of the nmserver interface depended
upon the old IPC structure. nmserver was also going to need lots of
porting, being involved with Mach messaging as deeply as it was. For
DO, continuing to use Mach messages, and provide named-object lookup,
now via the bootstrap server rather than nmserver, provided the best
porting/compatibility path, but also meant that cross-machine DO was not
going to happen that way; DO has had support (since OPENSTEP 4.0) for
doing your own transport however, so that was an "out" there.
* nmserver code base. The code was hard to maintain, complicated, and
hard to port to other platforms (Mach 3.0 was nearly different enough to
qualify as another platform, as well.) Years of experience demonstrated
this.
* nmserver protocol. To be useful for cross-platform (X Server <-> X)
communication, the "protocol" nmserver used over the internet would have
to remain the same, as it had had to remain the same for years and
across platforms already. However, there were design problems with the
protocol that made things brittle, made resource usage by the nmserver a
problem, and caused maintenance headaches. Preserving nmserver
interface semantics with untyped IPC on X was also going to be a minor
research problem.
* Undesirable for PDO. By PDO 4.0 (for those of you who've been around
a while), it was clear that nmserver was an undesirable aspect of the
PDO product. It was a pain to port, could use lots of resources during
execution, had to be running as a daemon (lots of customers didn't like
to have it running), was fragile, and caused a lot of support problems.
It was also the primary client of the whole Mach-emulation APIs and the
machd server in PDO. The Mach emulation strategy also clearly needed
more effort than it was worth. If Cocoa or PDO is ever ported to other
platforms again, it was likely I was going to have to deal with it
myself, not a pleasant prospect given the above, as others who had dealt
with it in the past have gone elsewhere. If I'm still around when and
if that ever happens, there will be no attempt at Mach emulation in such
a thing, and native facilities will be used underneath the higher-level
functionalities like DO.
* DO. The only client of nmserver we cared about was DO. It was also
unclear where the resources to port and maintain nmserver long-term
would come from or whether they'd be reliably there (nobody wanted to
touch it). The resources could have been found if we needed nmserver,
but it was clear we didn't have to have it. Looking at that, the
factors above, and the fact that it would be relatively easy to port DO
to Mach 3.0 (and other platforms) without having it, I recommended we
dump it, and it was so.> If someone writes this, it would be great to get the source out
> there... or document how to do it on Stepwise.. ;-)
It was our intention 3 years ago when Mach 3.0 came along that Cocoa
would provide this. We did changes to DO API and implementation, as I
said in my previous mail, to ease custom transport writing, and even
added an NSSocketPort class for that purpose. But the new Foundation
example for this remains unwritten. It's also possible that
NSSocketPort has bugs in it that we don't know about, since it isn't
exercised in unusual ways beyond the basic testing we have done. I
think named-lookup with it also remains unfinished. Someone else wrote
and owns that.
Chris Kane
Cocoa Frameworks, Apple, Inc.
