commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: [PROPOSAL] Commons Runtime API for Persistence
Date Sat, 02 Apr 2005 05:51:08 GMT
On Apr 1, 2005 8:14 PM, Jim Seach <jwseach@yahoo.com> wrote:
> Well, we could take it a step further:
> 
> We don't need to invent our own api, just adopt one and write the
> necessary adapters.  I propose using the JDBC api with our own
> DriverManager and DataSources.  The application or library developer
> will handle their persistence needs using the standard JDBC api, and
> our adapters will intercept the calls and translate them into calls on
> the desired persistence layer.
> 
> Does it matter that your post was sent past Midnight GMT?  It is still
> Friday in both yours and my time zones.

Mine too. I'm enjoying this thread. ;-)

--
Martin Cooper


> --- "Geir Magnusson Jr." <geirm@apache.org> wrote:
> >
> > a.k.a. "Commons Persisting"
> >
> > Motivation
> > ----------
> > There are an increasing number of viable APIs for persisting objects
> > to
> > data stores.  We currently have JDO, a JCP spec, Hibernate, a popular
> >
> > open source project, OJB, an Apache open source project, EJB3, a new
> > JCP spec for object persistence,  commercial products such as
> > Toplink,
> > and many others such as Abra, BasicWebLib, Castor, Cayenne, DataBind,
> >
> > DBVisual Architect, EnterpriseObjectsFrameworks, Expresso, FireStorm,
> >
> > iBATIS, Infobjects, InterSystems Cache, JULP, Jaxor, JDX, Kodo, LiDO,
> >
> > O/R Broker, Planet J's WOW, intelliBO, SimplOrm, Spadesoft XJDO,
> > Sql2Java, PE:J, VBSF and others.
> >
> > Each of these solutions have strengths and weaknesses and are chosen
> > by
> > developers based on specific project needs, political considerations,
> >
> > or quality of golf outings provided by the technology salesperson.
> >
> > Like the situation that developed a few years ago with logging, in
> > which developers were forced to choose between the de-facto standard,
> >
> > Apache Log4J, or the JCP-defined spec, java.util.logging, we believe
> > that we have a similar situation today - developers are forced to
> > commit to an API or product for persisting objects which may limit
> > usefulness to users who may have a legacy persisting technology, or
> > choose an different technology than the software was developed for.
> > Further, there is no way to insulate software from "API lock-in", to
> > allow software to be used with different persisting APIs as style,
> > fads
> > and technology concerns dictate.  Finally, there is no way to ensure
> > that arbitrary dependencies that a project uses can, in an ad-hoc
> > way,
> > find and write to the application's data store.  In the same way that
> >
> > components using commons-logging never cease to delight and surprise
> > users, we think that commons persisting should just enhance the
> > mystery
> > and intrigue of adding apparently innocuous dependencies to a
> > project.
> >
> > Proposal
> > --------
> >
> > Following the successful model of "Commons Logging", we propose to
> > create a single API, to be known as "Commons Persisting" which allows
> >
> > isolation from the fashions and trends in persisting technology.
> >
> > This API will not :
> >
> > - define a query language similar to any other
> > - define a query language conforming to standard set thEory
> > - define an O/R mapping metadata syntax
> > - define rules for object lifecycle with respect to the methods in
> > this
> > API
> > - use <insert favorite unproven technology here>
> > - constrain the types of objects and object models that a given
> > plug-in
> > might support
> > - keep Hani quiet
> >
> > This API will :
> >
> > - allow users to use one set of simple interfaces for persisting
> > objects
> > - allow different providers to be "plugged-in"
> > - define an API for execution of queries
> > - piss off various and sundry expert group members
> >
> > Comments?
> >
> > --
> > Geir Magnusson Jr                                  +1-203-665-6437
> > geirm@apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message