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

[Gregor Zeitlinger <zeitling informatik hu-berlin de>]

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
> overhead.
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 
> re-created.
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