Re: [xml] running libxml in kernel space (fwd)
- From: Gianni Mariani <gianni mariani ws>
- To: xml gnome org
- Subject: Re: [xml] running libxml in kernel space (fwd)
- Date: Thu, 13 Nov 2003 09:32:42 -0800
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]