[mdr-dev] MDR, MOF2, JMI2, ...

[Petr Hrebejk]

Hi MDR fans,

I have to apologize for at least two things:

1st I'm sorry for taking me so long to write this mail.
2nd I'm sorry that it will take some more time before you will know answers for
all the questions you have.

I'm currently looking at what usages for MDR Sun has. It looks like there are
some. However I need to know all the internal usecases before I'll be able to
answer questions like will we move to MOF 2.0, will it be EMOF or CMOF, etc.?

I have a few questions for all of you who use the MDR. Is there a possibility
that the community around MDR will cooperate on the development? How much work
are MDR users prepared to invest into MDR?
I dare to ask these questions as I know that the MDR community already proved
it's willingness to help.

Thanks
HREBEJK

[topping]

On Dec 4, 2005, at 10:09 AM, Petr Hrebejk wrote:

I have a few questions for all of you who use the MDR. Is there a possibility that the community around MDR will cooperate on the development? How much work are MDR users prepared to invest into MDR?

My interest is proportional to the direction that the next revision goes.  In order that this work could serve as long as the existing MDR has, I would like to see it rewritten from scratch with the latest in a few areas:

1) Code generation (if it is still deemed necessary) is done with a toolkit like http://asm.objectweb.org/ instead of straight bytecode manipulation.

2) Component management is handled by an open source IOC container instead of lookup routines from the Netbeans runtime.

3) Repository access is done through something like JDO instead of internal DBM-style management.  This one is a bit more complex, but JDO spec includes a flat-file backing store as well as SQL, and it should get MDR much closer to being runtime configurable for robust storage on SQL.

I also find that it's very important that the license it is distributed under allows binaries to be posted to locations such as the Maven repository at http://ibiblio.org/maven.  Having to log in, jump through hoops to download the latest, then extract the important jars from the results is an unnecessary barrier to entry and source of additional costs for users.  

Other than those minor details, I'm ready to get started right away! :-)

-b