Re: Implementation Repository

James Waller wrote:

>Judging from what I've been reading so far, there is
>one major difference between the design I have worked
>on and the one being agreed here. That is, my ImR
>works on the premise that you don't register each and
>every object with the ImR, instead you register the
>POAs that contain the objects (as described in the
>Henning paper).
>  
>

Not quite.  Each IOR for a persistent object must be generated by the 
ImR, that much is true.  But the ImR does not store per-object 
information.  That would not scale well.  Some load balancing ideas I'm 
working on in parallel with this ImR work would require the ImR to store 
object references for all *active* replica objects.  I don't see any way 
around that.

The ImR prototype and IDL I've posted has 2 ways to create a persistent 
reference.  The generatePersistent is used to create a reference based 
solely on the info passed in.  The ImR does not remember anything about 
the call.  makePersistent must be called from a currently registered 
server process, but even then, the ImR does not add anything to it's 
persistent store when creating the indirect reference.  All of the 
needed info is encoded into the indirect reference itself.

The difference I see in your IDL is that you tie things to POA 
identities.  That's perfect if the POAs themselves cooperate.  If not, I 
see no reason to force the concept of a POA identity into the ImR.  Its 
still a valid partitioning of the location domain, but perhaps not the 
only one.

>Originally I felt that the advantages of that approach
>outweighed the disadvantages. With hindsight, the
>other approach would have made my ImR *much* simpler
>(there's quite a bit of code in there for manipulating
>object references, POAs and so on). Maybe the ImR
>could make both methods available, the
>register-every-object way for portable servers and the
>register-every-POA way for more scalable (but
>non-portable) servers. Comments anyone?
>  
>

Are you saying you've modified the POA itself?  You may have to convince 
Duncan to merge your code if so.  I like the portable approach, since I 
don't see the explicit creation of the persistent references to be much 
of a burden.  Portable Helper libraries to ease the job of the server 
processes should be part of the ImR project.

Are you planning to release your ImR under an open license?  I'd be 
interested in seeing the code.

Kendall