[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: Fw: Ozone and XPATH
Hi Falko,
>
> ozone supports XPath. It employs third party packages like Xt or Xalan for
> that. The default is Xt which is included in CVS. Xt is pretty
> fast. If the
> working set of data fits in memory, then Xt works on persistent
> DOM (ozone)
> nearly as fast as on transient DOM.
>
> The is the drawback of the current architecture of ozone/XML.
> Which is very
> flexible and works with each products that uses DOM (Xt, Xalan,
> SAXON, ...) but
> on the other hand need enough memory to hold the working set of
> data in memory.
>
So the important thing is, that everything should be in Memory. That`s no
problem since the rules for the Content Management part could sort out
the articles i (eh, some script) wish to check out.
So, could i build a smaller working set of the overall database on the fly
fast?
The system`s rules could easily get the Article IDs (all Download-News for
the
last 29 Days or so). Would that ID list be suitable to build a working set?
The main question is, if it makes sense in these days to store XML data
in the file system (which is fast if you`re using RAID and/or Reiser FS)
and parse the content from there or if it is a better solution to use a
suitable database. Ozone seems to be suitable.
Another solution is to use a database like mySQL as "structured main memory"
and then let the parser look into a text field of the database.
I do not like to start a flame war here. There are good reasons to follow
each
path and i guess i would have to check them all out to be sure.
Juergen