Martin Cooper wrote:
>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. ;-)
>
>
Still Friday here...another great struts contribution to commons :-))
Phil
>--
>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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org