ImR prototype/proof-of-concept

[email protected] Mon, 27 Jan 2003 22:10:27 +0000
Newsgroups gmane.comp.corba.omniorb.devel
Message-ID <20030127221028.ODCT2338.sccmmhc01.mchsi.com@sccqwbc04>
The code contained here is meant to be a prototype/proof-of-concept *only*.
It's purpose is to further the discussion among the omniORB-dev group with
respect to the development of a portable Implementation Repository (ImR) service
for use in omniORB or mixed ORB environments (or even to replace another ORB's
ImR if so desired).

Some known/intentional problems/ommissions:
============================================
1) little/no error handling
2) not thread safe.  No locking, and no use of synchronization primitive to
coordinate needed communication between threads.  Saving of ImR state is not
thread-safe at all.
3) no graceful way to shut down ImR.py or test/server.py
4) persistence of ImR state is inefficient.  Any change to the state causes the
full state to get re-serialized using cPickle.

Topics for discussion:
=======================
- Correctness/completeness of imr.idl and imradmin.idl
- Persistence strategy for the ImR
- Details of the server auto-start mechanism.  Local vs. remote process launching.
  The right way/portable way to start a daemon process / Windows Service?
- Logging, graceful shutdown, error handling, other boiler-plate.


Kendall
imr.tgz (application/x-tar, 12.6 KB) - not displayed