🚀 go-pugleaf

Vidur Dhanda <vdhanda@active-solutions-inc.com> writes:

> I guess, ideally, I want the "primary" object to live on the server, and
> have the ability to migrate a copy/replica to the client.  However, I do
> not want to migrate the entire object but only as much as is required
> and can be "efficiently" transferred.  I suppose that would at least
> suggest not sending embedded collections unless required.  Does this
> make any sense and where would I look for further information?  Or am I
> totally missing the mark?

You might find the following paper helpful for some background
information on these issues:

    http://www.inf.fu-berlin.de/inst/pubs/tr-b-98-13.abstract.html

Basically, I think you are trying to do something for which current
mainstream distribution technology just isn't powerful or flexible
enough.  The main problems with Java/RMI are that

  (1) RMI makes it a property of the _type_ of an object whether it
      should be passed by value (copied to remote sites) or by
      reference (stay on the server and access it remotely).  But in
      situations like yours you want more flexibility, e.g. to decide
      on parameter passing modes per _method_ or per _parameter_.  The
      upcoming CORBA Objects-by-Value will be somewhat closer to this.

  (2) Copying object state around (as RMI's serialization does) is
      only a poor substitute for true object migration (where
      references are redirected so that an object always only exists
      at a single place in the system), or object caching.  Migration
      and caching should be controllable both statically in the code
      (e.g. passing modes such as pass-by-move or pass-by-visit) and
      dynamically by a run-time system that moves or caches objects to
      optimize communication behaviour.  Research systems like Emerald
      or Orca demonstrated this ten years ago, but there is no
      off-the-shelf technology that does this for you yet.

Sorry for this rather academic remark, but I believe you are simply
pushing the current technology to its limits, which also explains why
there is little practical advice on such issues yet -- people are just
beginning to do this on a large scale, and technology is still
struggling to keep pace with that.  See the above paper for references
to some more experimental distribution platforms that, I believe, are
much closer to your needs already.

As for a real practical solution of your problem, I think what David
Pirkle wrote is about as good as it currently gets.

Regards,

Andre Spiegel
Free University of Berlin