DO: Local objects passed back from the other side: Leopard vs. earlier systems
DO: Local objects passed back from the other side: Leopard vs. earlier systems
- Subject: DO: Local objects passed back from the other side: Leopard vs. earlier systems
- From: Grigory Entin <email@hidden>
- Date: Wed, 07 Nov 2007 03:59:36 +0300
Hi,
Sorry for the long post..
Consider this (*inter-thread Distrubuted Objects communication inside
a single app*):
1. client is an (real/local) object on "client" side
2. server is an (real/local) object on "server" side
3. someone on "client" side performs [server serve: client] call
4. as part of the -serve: method, on "server" side server passes back
the reference to client, via [client callback: client] call (client
here is the value of parameter for -serve: visible on "server"
side, apparently it's a proxy)
I used to believe that on "client" side in -callback: client will get
*real* object passed as parameter, because it belongs to the same side
of communication and therefore there's no need to wrap it (see
below). Actually, I still believe it is the case on pre-Leopard
systems. However, it looks like on Leopard it's no longer the case - I
get NSDistantObject proxy that wraps the real object. (Just in case,
on Leopard, I still see the original object among the localObjects for
connectionForProxy for that proxy, so the object is "local" from that
point too.)
Question 1: is it true that I can not rely on *real* objects passed
back after they trip to the "server" side (e.g. for the simpliest DO
case (multiple-threads/single app))?
I do understand, that probably it is *not* documented, that one should
expect real objects when they get "returned back" after travelling
over DO connection, but that sounded sane for me (from the point of
simplicity and performance), at least in the simpliest case.
Unfortunately, now it has some real life implications for me. E.g. I
used to pass the "returned" objects as object parameter to
-[NSNotificationCenter addObserver:selector:name:object:], and as
result, notifications do not "fire" when they're triggered with *real*
objects passed as object: in -postNotificationName:object:userInfo:.
So far, I tried to do some workarounds to ensure that I get *real*
objects after "the trip to other side" on Leopard, e.g. by defining a
method in a class category for those objects, but that doesn't sound
like the "best"/"right" solution.
Question 2: is there way to trigger the "original"/pre-Leopard
behavior on Leopard, i.e. see the real local objects instead of
"distant objects" when the objects are passed back from the other
side?
Question 3: is there way to obtain the real object from
NSDistantObject that is passed back to the "original" side, when it is
indeed local for the connection?
Any suggestions/comments?
Just in case, the observed behavior can be 100% reproduced via a
simple modification of TrivialThreads example posted on Apple site. I
can provide it if necessary.
Regards,
Grigory
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden