Revision 1 as of 2005-03-22 05:43:34
missing edit-log entry for this revision
converted to 1.6 markup
|No differences found!|
Thomas brought this up and I think it is the most important thing going forward. One of the points of OJB is that it is easy to use it to implement arbitrary object persistence to arbitrary backends. Thomas is working on a Prevayler backed PersistenceBroker, I want to experiment with a couple alternative querying mechanisms, etc.
There are a couple facets to the ApiSpi seperation as I see them. The first is a clean SPI for tools mapping to a persistence back end. This would be implemented by a relational database SPI, a JNDI SPI, etc. It serves as an interface to the persistence mechanism. An OJB to CMP SPI would be entertaining
The API side is the client API to OJB's persistence mechanism. In theory everything is built on top of the PersistenceBroker right now, but the ODMG implementation is off in its own world. The PersistenceBrokerAPI and the OTM are the two "low level" API's upon which other services can and should be built. The design of those API's should be around enabling higher level API's to be built on them, rather than being as convenient as possible as a client API in their own rights.
The PersistenceBrokerAPI is the designated PersistenceKernel for OJB and should be refactored with this in mind. The stated intention is to move the ODMG implementation on top of the OTM, and then the JDOSupport as well. I think that the OTM should only support the PersistenceBrokerAPI as a client API in order to keep it more maintainable (as of this writing it supported OQL and PersistenceBokerAPI style queries. --BrianMcCallister