Re: Looking for a good PDOM

[Marcel Ruff <ruff@swand.lake.de>]

Falko Braeutigam wrote:
> 
> On Mon, 17 Apr 2000, you wrote:
> > Hi,
> >
> > we are looking for a free persistent DOM implementation.
> ozone/XML is 100% Java
Good.

> > The PDOM should cache parts of the DOM tree to/from harddisk
> > transparently, so that the XPath/XSLT engine doesn't notice it.
> ozone works this way (not only for DOM objects, btw ;)
Even better.

> 
> >
> > Here is our wish list :-)
> >
> > - Free for commercials as well (like LGPL or similar)
> the ozone public APIs are under LGPL. The DOM code that we are currenly using
> is a port of OpenXML which is ok for commercial use too.
Excellent.

> 
> >
> > - Allowing to use any XSL engine (we use currently XT from J.Clark
> >   to query the DOM with XPath, since it is the fastest engine)
> We have tried Lotus and Xalan without problems. It should work also with XT.
Good.

> 
> >
> > - Should work non validated as well (no dtd, since the DOM is generic).
> ozone/XML basically provides the persistent DOM. It can be used with any parser.
?


> > Could ozone be a solution for this?
> Yes, I think so. BUT, since ozone/XML is based on the general purpose OODBMS
> it is not as fast as deticated XML storage solutions, yet ;) (see the excelon
> comparison thread) And the programming must follow ozone programming rules.
> This means any DOM query and manipulation should be done on the server for
> performance reasons.
Yes, the same with us. XPath queries are passed by CORBA or http or
whatever
and run on the server.

Is it possible to extract only the PDOM code from ozone
without any RMI or whatever as we look for maximum speed?

Is the performance degraded, even when everything fits into memory?
This is important for us, since most time the DOM fits into RAM.

Can we choose an arbitrary XML parser and ozone persitency plugs in?
Now we use Sun XML parser and enjoy some nonestandard api calls
(especially to merge two DOM trees into on). This we would need
to code self if ozone DOM doesn't like it (and could be much
slower than the Sun internal merge).

> 
> Right now I'm working on a client site cache that should cure both problems. I
> will post news here. On the other hand, if your XML documents are actually to
> big to fit into memory, than a client site cache makes no sense for you in any
> case and the server site processing of the current ozone/XML is the best choice
> for you.
Yes.

thanks a lot,

Marcel


-- 
Marcel Ruff
ruff@swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org