Persistent Objects

[Chris Hafey]

> 2. Make sure that the same object key is used to identify the object 
>    implementation. omniORB provides a ctor in the implementation skeleton
>    class that takes an object key as an argument and uses that to identify
>    the object (section 2.4.2 of the user guide). The object key is an
>    opaque type but can be converted to and from a sequence of octets
>    using the utility functions described in section 3.3 of the user guide.

  I would really like to see support for user defined keys.  The ability
to use the same object key in the database and the ORB has significant 
advantages.  Ideally this would be implemented as an octet sequence.
Proxy object key are already maintained this way but I haven't spent 
enough time in the code to see how this applies to local objects.  Thoughts?
  On another note, I would really like to know what ORL's plans are for 
OmniORB's development.  I believe in the future of CORBA and expect to see
a GPLd COBRA implementation at least as popular as Linux is today.  To
achieve this, we need to develop a complete CORBA solution.  We need someone
to manage the growth and development of omniORB (like Linus did for Linux).
Could someone at ORL answer the following questions:

a) Which features are currently under development and when can they be 
   expected? (I know about DII/DSI/Type Any, but when are they due?)
b) What is ORL's position in regard to future omniORB development?  Is ORL
   getting out of ORB development or will resources be allocated?

Major development projects include:
1) Interface Repository
2) POA support (it would be nice to be the first ORB to support the POA)
3) Implement the Security service
4) Implement the Transaction service 

Chris Hafey