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

[Gianni Mariani <gianni mariani ws>]

Gregor Zeitlinger wrote:

> On Thu, 13 Nov 2003, Daniel Veillard wrote:
>  
>
> >  Okay then here is a few points I would like to raise:
> >    - If possible keep all XML processing in user space. XML processing
> >      CPU requirement cannot be bounded.
> >    
> can a kernel component call a user space component to do the parsing?
>
>  
>
> >    - if you still need some kind of XML processing in-kernel then drop
> >      XML, use a subset, call it RFSML or whatever but not XML
> >    
> that might be OK for a start. The intention is to create a reiserfs plugin
> for xml. This plugin would take responsiblity to store xml files in
> reiserfs in such a way that you can easily access it. you could view it as
> directory (using so-called pseudo files) or use xpath.
> The idea is kinda similar to WinFS.
One alternative is to place a "binary" representation of the XML file 
into the tree.  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.  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.

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.  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 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 ?

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.  I can imagine easier 
ways to place this kind of file under a Reiser plug-in compared to a 
full featured XML file.