Re: AW: [Objectbridge-jdo-dev] Introduction

[Joel S. <jo...@ik...>]

I apologize for being quiet for a few days. "Real life" got a little
crazy.

On Wed, 2002-04-10 at 01:14, Mahler Thomas wrote:
> > Does everybody here (both communities) want this to work, and 
> > if so, what is
> > the next step?
> > 
> 
> I think it is the best way to go. So we should do it!
> 
> I think we have to clarify responsibilities. These can be easily deduced
> from the tasks we have to accomplish:
> 
> 1) JDO front end with pluggable store interface
> 2) O/R mapping store
> 3) Object db store
> 
> 2 and 3 are simple:
> 3.) is developed by the sparrow team
> 2.) is developed by the OJB team

Maybe... see below.

> We don't need shared or synchronized repositories for these. They can be
> developed quite independently.

Agreed. And that will be a project goal--that "pluggable stores" will be
able to easily evolve separate of the front end JDO impl. I do want to
keep things open for optimizations though. There may be situations where
we specific stores might want to override certain classes or something
to make things extremely fast/optimized. This can be designed in as we
go along, though and is optional.

I guess what I'm trying to say is an elegant modular architecture with
support for a "fasttrack" pipeline for optimized stores.

Modularity is great... but especially for my vision of a JDO object
store, I would really like it to scream.

> 1.) can be decomposed into two subtasks:
> 1a) JDO front end (incl. JDO instance lifecycle, code enhancement, etc.)
> 1b) Defining a Store interface that allows pluggable implementations.
> 
> The OJB team is currently just working on prototypes based on suns RI.
> The sparrow team seems to have at leat some code working.
> SO I would suggest:
> 1a.) is done by the Sparrow team
> 1b.) will be maintained by the SParrow team too, but the OJB team is
> involved in developing this interface.
> 
> So 1.) could also lie in the Sparrow team responsibility.

I'm going to respond to the rest of the conversation at this time as
well. Again, sorry for the delay.

I would like to second your suggestion that Sparrow do #1 because... #3
might not be part of the Sparrow project after all. For example, I
mentioned Ozone. Sparrow could be the front JDO with pluggable stores
architecture, and Ozone or other object databases could then do their
own work to conform to that pluggable architecture.

Thus... let's call Sparrow the front end JDO architecture and if I
decide to do a new optimized object storage for it (which I would really
like to but don't know if I'll have time), that could be the third
project.

How does that sound?
-- 
Joel Shellman
Comprehensive Internet Solutions -- Building business dreams.
[ web design | database | e-commerce | hosting | marketing ]
iKestrel, Inc.  http://www.ikestrel.com/