mikeash.com pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html commentshttp://www.mikeash.com/?page=pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html#commentsmikeash.com Recent CommentsThu, 28 Mar 2024 18:52:07 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssمسجات صباحية - 2016-09-30 15:46:13http://www.mikeash.com/?page=pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html#commentsA more benign failure mode would be useful, certainly. That's actually something that you could add yourself with a little NSProxy subclass. The bad news is that it would require an explicit check and instantiation of your proxy class in all code that could obtain a distant object.224ed9316d2a1ae9d730399646a8db58Fri, 30 Sep 2016 15:46:13 GMTMaynard Handley - 2013-10-02 07:39:40http://www.mikeash.com/?page=pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html#commentsIs it possible that distributed objects (with a small d, small o; ie the concept, not Apple's implementation) is simply a bad abstraction? <br /> <br />There are a number of abstractions that seemed cool from an engineering standpoint (RPC, networked VM, publish-and-subscribe, DDE then OLE) but which basically never took off. In at least some of these cases there has been massive company pressure behind them, but no real traction among users or developers. These things seem to be what I'll call "bad abstractions". They're trying to solve a problem by reducing it to an already solved problem, but the gap between the reality and the metaphor is just too large to be straddled. <br /> <br />In the 90s there was this whole industry that grew up around the idea that computers would talk to servers via RPC and distributed objects, and it didn't happen. Not because talking to servers was a bad idea but, as far as I can tell, because talking to servers using network-aware constructs (and with the consequences in terms of making errors --- the errors specific to networks --- more visible, but also then easier to handle appropriately). And so --- HTTP. <br />Similarly with RPC where it's still done, of course, but with things like REST and SOAP, not the classic SUN-style RPC. <br /> <br />We saw a similar thing with presentation where, rather than the "one GUI everywhere" idea of Java (and some competitors) the solution that won didn't exactly pretend to be something it wasn't. HTML wasn't powerful, but it did what it did in a way that matched the task to be solved, it didn't create a UI layer that sorta pretended to be Mac or Windows while not actually working like either. <br /> <br />Point is --- Apple have probably look at this history and concluded that, regardless of what people might claim, distributed objects is a loser technology, and there's no point in trying to make it work better. If you want to do anything serious over the network, you're probably going to be a lot happier using network appropriate primitives rather than trying to hide the existence of the network. 5fd7d9c38a180a776bf9c7e82d4fffbdWed, 02 Oct 2013 07:39:40 GMTSteven Degutis - 2009-12-28 16:51:49http://www.mikeash.com/?page=pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html#commentsOh okay, thanks for clarifying, I understand better now.443142bd386a6933ee56e4c9692ded7bMon, 28 Dec 2009 16:51:49 GMTmikeash - 2009-12-28 15:55:28http://www.mikeash.com/?page=pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html#commentsIt's not calling hash on an NSSet, it's NSSet calling hash on your object, and this call throws an exception because the DO connection died. Imagine code structured like this: <br /><code> <br />@interface NSSet <br /> <br />- (void)doSomeThing <br />{ <br />&nbsp;&nbsp;&nbsp;&nbsp;[self startTheThing]; <br />&nbsp;&nbsp;&nbsp;&nbsp;[self findBucket: [yourObject hash]]; <br />&nbsp;&nbsp;&nbsp;&nbsp;[self endTheThing]; <br />} <br /> <br />@end <br /></code> <br />If startTheThing puts the set into an inconsistent state, and endTheThing completes the work and puts the set back where it was, throwing an exception inside hash will cause problems.a0562cfb7fb07e3646de2abbc5215ea9Mon, 28 Dec 2009 15:55:28 GMTSteven Degutis - 2009-12-28 15:49:18http://www.mikeash.com/?page=pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html#commentsI'm a little confused about your hypothetical of calling -hash on an NSSet with DO and having that set be left in an inconsistent state. Could you please elaborate on this example?a7441bf7f759c657a4b002feebf1d8abMon, 28 Dec 2009 15:49:18 GMTmikeash - 2009-02-21 23:36:08http://www.mikeash.com/?page=pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html#commentsI've never used DO and GC together so this is purely theory, but I don't think there would be a problem. Memory management stays internal to each process. Proxies get created in each process, and those proxies will live or die by the memory management system in use in that process. The major problem with GC is that I don't believe that circular references which cross over the DO boundary will be collected, because the collector can't trace the connections in the remote process.9e671064047b61a0aa35d906ebd6d699Sat, 21 Feb 2009 23:36:08 GMTNikita Zhuk - 2009-02-21 21:21:46http://www.mikeash.com/?page=pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html#commentsAre there any potential problems developers should be aware of when using DO between processes of which one is running under GC and another's memory is managed manually? There have been some posts on mailing lists about some problems potentially related to DO &amp; GC. I haven't noticed any problems with this setup myself yet, though. <br /> <br />In my own Cocoa projects I have noticed that DO's transparency disappears pretty quickly in practice when one starts to build exception-catching, operation-retrying, non-blocking, time outing proxies around objects vended over DO. However, it still seems like a good choice for IPC between two Cocoa processes.d0897a752dd3e55004c2f0e5cde84d3eSat, 21 Feb 2009 21:21:46 GMTmikeash - 2009-02-21 07:19:48http://www.mikeash.com/?page=pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html#commentsHaving dropped objects become nil is problematic for various reasons. First, there's no way to find all references to an object and reliably nil them out (not even under GC, zeroing weak references are a special case and only work in heap memory). Second, having the contents of a Cocoa collections class which doesn't allow nil to suddenly become nil would be a bad thing. <br /> <br />A more benign failure mode would be useful, certainly. That's actually something that you could add yourself with a little NSProxy subclass. The bad news is that it would require an explicit check and instantiation of your proxy class in all code that could obtain a distant object.775f072559dbb87bb541784250048970Sat, 21 Feb 2009 07:19:48 GMTJordy/Jediknil - 2009-02-21 04:53:34http://www.mikeash.com/?page=pyblog/friday-qa-2009-02-20-the-good-and-bad-of-distributed-objects.html#commentsI love the idea of DO, but the problems rearing up can be huge. It's much easier to use DO for quick communications than to actually hang on to a remote object. <br /> <br />You forgot one thing, too. DO uses NSCoding to send objects, but AFAIK it doesn't support keyed coding. Which means you need to keep supporting the much more easy-to-break unkeyed system, which is all but legacy now. <br /> <br />I wish DO+GC resulted in dropped objects becoming nil, or that you could set something so that return values became nil when the connection disappears. Throwing an exception is one of the more inconvenient choices for signaling this error.2600205edbfffbacda7474cf37487689Sat, 21 Feb 2009 04:53:34 GMT