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