[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

No Subject



Hi all, short status report of the ozone development:

Core Development
----------------
In the 0.3.3 version I have separated store back-end from the core code. The
current implementation of the store back-end is in the xxx.core.classicStore
module. The contract between core and store is defined by the Store and the
ObjectContainer interfaces. This works so far but the interface is not as clean
as we need it. So I have started to completely re-design Store/ObjectContainer
interface, Transaction interface and concurrency control. Goals:

- clean and small Store interface that makes it easy to develop new Store
back-ends (especially one that handles DOM-like applications well)

- clean and small concurrence control interface that makes it easy to develop
and plug-in new concurrency control policies. (besides the default pessimistic
locking)

- clean and smart core architecture to make the whole thing maintainable and
extendable 

Right now I'm trying to define the new Java interface and class signatures.
Nothing compiles or runs so far. Ideas, comments, whatever welcome.

XML Development
---------------
Lars and Conny are about to implement the new xxx.xml.repository.Repository
class. The idea is to use XPath to search within documents _and_ to search
documents. XLink is used to link from "access path" documents/DOM trees to data
documents.

Using the XML repository it should be easy to make a simple document management
system. As soon as the repository works we will use it for a publishing system
that uses Cocoon as front-end. A first public release of the XML repository can
be expected to be available next week.

Here is the current Java interface pasted right out of Lars' editor ;)

public interface Repository extends OzoneRemote {
    public void init (String parserName)  throws Exception;
    public Document getRootDocument ();
    public void setRootDocument (byte[] data) throws Exception;
    public Document storeDocument (byte[] data, String docName, int access) throws Exception;
    public Document storeDocument (Document memDoc, String docName, int access) throws Exception;
    public void linkDocument (Element from, Document to);
    public Document unlinkDocument (Element from);
    public NodeList xpathQuery (Document pDom);
    public NodeList xpathQuery (String qString, Document pDom);
    public void addDocument (byte[] data, Element where, int access);
    public void deleteDocument (Element where);
    public String getParserName ();
    public void setParserName (String parserName) throws Exception;
    }

ODMG Development
----------------
We have started to play with the JavaClass package to modify the byte code of
database classes. Seems to work as expected so far. We need this because ODMG
does not define createObject() or deleteObject() methods. So the constructor of
the proxies have to implicitely create proper in-database objects when they are
constructed. (!) 
Things that are needed for ODMG:

- enhanced OPP that generates proxies with correct constructors plus a helper
class that is responsible for method invoke and maybe serialization. (not
decided yet)

- some kind of a "deployment descriptor" that describes lock type of methods
and myabe other things like the store back-end in which this object will live.

- class converter that converts byte code of database classes and files it to
the database.

- "long" transactions 


Falko
-- 
______________________________________________________________________
Falko Braeutigam                         mailto:falko@softwarebuero.de
softwarebuero m&b (SMB)                    http://www.softwarebuero.de