Re: [Objectbridge-jdo-dev] Introduction

[Andy L. <aj...@as...>]

THis threasd begs several questions...most of them having to do with
tactical issues. Where would primary CVS fro the JDO core reside? What group
would govern it's progress and development?

(Joel is probalby tired of me asking questions like this...) One of the
things that irs critical to making most (if not all) open source communities
thrive is a clarity of basic governing procedures. I'm not familiar enough
with ORB to know how it has been done in the past...

I've been watching open source projects around JDO for quite a while, and
really want to see a good implementation....

Does everybody here (both communities) want this to work, and if so, what is
the next step?



> Hi Joel,
>
> Joel Shellman wrote:
>
> <snip intro>
>>
>>>What are your ideas?
>>>Do you also focus on O/R mapping or do you want to build a JDO
>>>compliant OODB?
>>>
>>
>> I'd like to see both done, though I see a huge advantage to having a
>> JDO compliant OODB. It would make life so easy. That's why I've been
>> working with Ozone (object db).
>
>
> I know Ozone a little. They also provide a ODMG Api, though not very
> complete.
>
>> It has some things I don't like though, which is
>> why I started Sparrow instead of just working with Ozone.
>>
>
>
> What exactly is there in Ozone that you don't like?
> Do you know DB40 (http://www.db4o.com)? it's a commercial OODBMS with a
>  liberal licence for personal use. The db4o people are trying to
> establish lighweight statndard API for OO data access
> (http://www.odbms.org). OJB provides support for their S.O.D.A API
> already. The ultimate aim is to allow free choice of the persistent
> media (ODBMS or RDBMS).
>
>
>> The bare minimum I see is:
>>
>> 1) JDO front end with pluggable store
>> 2) O/R mapping store
>> 3) Object db store
>>
>
>
> 1) and 2) are exactly the scope of OJB-JDO
> So their is really a large potential in joining our efforts!
>
> This picture also looks very similar to the original JDO RI by sun.
>
> I have an additional idea: what about using the OJB PersisteneBroker
> API  as the store API? going this way we will have the following
> picture:
>
> 1.) JDO and ODMG front ends, both working against a PersistenceBroker
> kernel internally
> 2.) several PersistenceBroker implementations:
> - for RDBMS (already implemented)
> - for LDAP (partially implemented)
> - for XML storage (some people already working on it)
> - for OODB (to be done by Sparrow)
>
> This would be a kind of "rosetta stone" of object persistence!
>
>
>> Might also need to be a separated pluggable transaction manager and
>> there's a good chance we would want to get a little more fine grained
>> with the above.
>>
>
>
> We are currently working on JTA and JCA support in OJB.
>
>
>> My goal is to get to as close as:
>>  - Drop in one or two jars and poof, you can now have persistent
>> objects. That's all it takes.
>>
>> The ideal might not be perfectly attainable, but I think it's possible
>> to come at least very very close.
>
>
> With a pure ODBMS approach this should be possible.
> With a O/R approach it won't be that easy. (You must tell the RDBMS
> about primary keys, foreign keys and indexes which is not so easy to
> deduce from an object model...)
> But it's not impossible to reach.
>
> I believe we can save a lot of work with such a joint venture.
>
> best regards,
>
> Thomas
>
>
>
>
>
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev


"The heights of genius are only measurable by the depths of stupidity."