Re: [xml] running libxml in kernel space (fwd)

On Thu, 13 Nov 2003, Gianni Mariani wrote:
One alternative is to place a "binary" representation of the XML file 
into the tree.
after the file has been imported into the database, it is stored in a
custom page format, a binary representation, if you will.

You can also optimize this so that the binary representation is
created on demand or asynchronously making reading and writing XML
text files with this "meta" file system support a smaller percieved
well, the file plugin is invoked on demand only. The conversion to the
binary representation could happen asynchronously, but that's definely not
a 1.0 feature.

Also, the cost of having an external "xml parser"  process that
processes XML files and creates the parsed binary version may be a
more palatable alternative than sticking the parser in kernel space.
yeah, maybe.

Thinking out aload - bummer - what happens if someone decides to "write" 
to an XML node, the text version is out of date and needs to be 
That clearly depends on how the interface is going to be. It may be
mandatory to use a special API for writing to those xml files.

I see all kinds of horror stories happening.  What happens 
if you lseek into the xml text of a file and update the text of a node, 
do you know how to re-parse the file ?  What happens when the file has 
an XML syntax error.
I guess if you use the legacy file write API, you have to reparse the
file. If you used the DOM API, this problem wouldn't exist. The neat thing
about reiserfs ist that the you can view the xml file as directory, which
_is_ the DOM API.

I can think of ways to achieve the same thing without the XML overhead, 
are you sure you want to create a new nest of problems ?
well, the whole idea is about having an xml database. I actually have it
already. I just want to port it to reiserfs.

A few years ago (before libxml2) I wrote a simpler XML-subset parser and 
we stored most of the xml files in a binary form. The serialization to 
and from DOM was lighting fast and predictable in performance.  The 
binary-xml library used memory mapped files and it had 3 main sections.
1. node list, 2. node connectivity and 3. strings. 
this is kinda like my xml database.

I can imagine easier ways to place this kind of file under a Reiser
plug-in compared to a full featured XML file.
but that's not the point

Gregor Zeitlinger
gregor zeitlinger de

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