Hi Diego...

I would like to weigh in with a few comments on this topic.  Well done
on putting rSt together.  I would like to help if there is anything you
need.  Dialect independent serialization, async messaging, reference
management.   more follows...

"Diego Gomez Deck" <DiegoGomezDeck at ConsultAr.com> wrote:
> Hello again...
> 
[snip]

> >Interesting. But shouldn't the framework hold a strong pointer to the
> >proxy and the proxy a weak pointer to the model? If I understand you
> >correctly than this would model your dependencies much better. If the
> >model goes away then the proxy can be destroyed on the client side. If
> >not, then it can only be destroyed via a remote message.

exactly.

> 
> The framework knows nothing how the objects are used... only pass remote-references to object that pass by-reference and copies for the other objects.  The remote-references objects (proxies) send every message that receives to the other side, more or less thats all (there are a gc work, but it's not relevant for this discussion)... When you receive a remote-refence (proxy) object you don't realize it, after all you only want to send messages.
>

Perhaps this is where we can effect a solution.  Certain message sends
are by their nature passing a weak reference.  These are the
#addDependent: and #when:send:to:, and their corresponding removal
messages.   

If you introduce a WeakRemoteObserver object, then those messages sent
to a RemoteObjectProxy should know which message sends are really
pass-by-weak-reference and use the appropriate Transporter. 
#(#addDependent: #when:send:to:)
 
In general, it is a remote observer pattern.  The lifecycle of the
object in imageA has nothing to do with the registration of that object
in imageB, but the registration (in B) needs to strongly hold onto the
remoteProxy so it doesn't go away, locally.  This should *not* be
included in the maintenance count, however. 

Perhaps use an inTable and an outTable in each broker.   This
remoteObserver pattern would look like:

  localObject -> broker (A) -> outTable (weak to localObject for
finalization messages)

  inTable (strong to remoteObserver) -> broker (B) -> remoteObserver

When  the localObject goes away, then inform the remoteBroker to remove
the remoteObserver.

I have recently been through a few cycles on my attempts at remote
objects and the most important thing I realized is that remote proxies
are not transparent from all aspects.  Typically it is more useful to
view these references as potentially broken (network/broker failures)
and that the context of use (the send) of a reference will dictate the
transformation that an argument will undergo.  (weak-reference,
strong-reference, copy).  Finally, messaging should be asynchronous,
which completely changes the ways we would interact with a remote
reference.

I hope this helps provide a different view of the issues.

cheers,
Rob