I agree with first sentence of the last comment that this is a recurring theme with many similar false mantras. I am not sure I quite agree that they are doomed.

Instead, I think that in most environments that there isn’t the necessary sophistication to make it work correctly. This has to do with many factors, but there is a dearth of developers/software architects with the requisite background, knowledge, and experience.

Any form of remoting is far more complex than most people realize. The “marketing” of it always glosses over the complexity for the “hyped” benefits. There are other approaches and architectural styles that can accomplish remoting but again these get more complex.

This has been a very fun topic to discuss.

David

Most distributed technologies work by reference. It doesn’t make sense to have the local application take over the object life cycle which would be the case with by copy. Typically the distributed environment takes over the responsibility for life cycle management so that local applications are “finding” or looking up the DO.

If you get a DO by copy then the local application is responsible for destroying or freeing the object up explicitly. All in all this generally adds network traffic and/or increasing distributed memory usage - some application always messes up the life cycle management - not a criticism but a reality.

This is typical for most (if not all) other distributed technologies. From the perspective of the local application it should not matter as long as the distributed environment ensures consistency for each distributed call - meaning that the reference used by instance A does not interfere with the reference used by instance B. This consistency and separation has been guaranteed by the distributed environment that I have worked with. Again, from the local perspective it shouldn’t matter whether the distributed environment shares the same object with different local instances as long as there is consistency from each call to each instance. I know this sounds complicated but this is not unusual with distributed object pools which are also fairly common. Good luck.

David

“NSObject’s implementation returns an NSDistantObject object for the object returned by replacementObjectForCoder:, enabling all objects to be distributed by proxy as the default.

Subclasses that want to be passed by copy instead of by reference must override this method and return self.”

Implementing NSCoding is not enough to tell DO that your object can be send bycopy as DO uses a coder that does not support keyed coding.

And I didn’t manage to figure the exact behavior for ‘deep copy’. I have a case where [encoder isCopy] returns YES for my top level object and NO for second level objects. I check with GDB that it was the same NSCoder instance.

I remember the problem with NSURL, though! We definitely ran into that in the iChatAgent. It took us a while to discover that all URLs were being sent as proxies, resulting in tons of unnecessary IPCs. We had to change all of those parameters to NSStrings.

The problem is that you don’t have any way to know which class override it, and which class do not. For instance, NSURL does not support ‘bycopy’ and is send ‘byref’. But I think all the property list classes support bycopy.

I think there is a very important place in development for DOs. However, I think most deployments don’t consider the range of issues. Additionally, it is true the coding DOs can be far more complex even with “code” generating IDE help.

story has entered the popular today section on popurls.com…