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



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.






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