[lcdproc] XML discussion

[Mindaugas Idzelis]

Matt wrote:

> William W. Ferrell wrote:
>
> | I'm beginning to have concerns about memory usage too. This thing simply
> | cannot explode violently into a several-megabyte memory hog.
>
> How complex are these XML "thingies" going to get? I don't think, (hope),
> we're going to be pushing the limits on memory usage. Are we?

Actually, on second thought, and second analysis of libxml, it is not all that
bad. It did manage to get it to compiler under cygwin. So that's a definate
plus. libxml is by default installed with gnome. So chances are your system
already has it (well, if you have the gnome-devel rpms) libxml for most people
won't involve a new download. If the library is not statically compiled into
the program, the file size is kept quite small.

The test programs compiled under linux are file sizes (dynamically linked):
-rwxrwxr-x    1 aim4min  aim4min      3813 Aug 24 16:43 testHTML
-rwxrwxr-x    1 aim4min  aim4min      3808 Aug 24 16:43 testSAX
-rwxrwxr-x    1 aim4min  aim4min      3808 Aug 24 16:43 testURI
-rwxrwxr-x    1 aim4min  aim4min      3818 Aug 24 16:43 testXPath

and under cygwin (statically linked -> statically linking is impossible, i
think??):
-rwxr-xr-x   1 midzelis unknown    347648 Aug 24 16:35 testHTML.exe
-rwxr-xr-x   1 midzelis unknown    305664 Aug 24 16:35 testSAX.exe
-rwxr-xr-x   1 midzelis unknown     16384 Aug 24 16:35 testURI.exe
-rwxr-xr-x   1 midzelis unknown    345088 Aug 24 16:35 testXPath.exe
-rwxr-xr-x   1 midzelis unknown    350720 Aug 24 16:35 xmllint.exe

So, we're definately not using windows as an embedded platform ;-)
Haven't done much mem usage, but since the config files are only going to be
10-30 lines long, it shouldn't be much. The docs say you might have problems
with memory if your trying to parse a 35Meg XML file using DOM interface. Sax
interface is easier on the memory, (doesn't generate a tree) but makes it
harder to write back to the file. In our case, we should stick with DOM.


>
>
> As the only XML enabled software should be the server, (which doesn't need
> to be ultra-compact), and this holds the majority of XML. The client
> should only need to be able to "print" it across the connection, with
> minimal parsing should the server respond with XML (?).

Well, again... if you have the libraries, xml parsing is easy.

>
>
> | Bugger. This would be very cool to get working and keep lean. Then again
> | I also just realized that if we go with xml for the protocol, anyone who
> | develops a client will have to have an xml library available and be able
> | to parse it.
>
> If the client is in C, it uses the same lib as we use for the server and
> packaged clients. Perl clients will use <quickly checks CPAN> the
> XML::Parser module. Does anyone use any other languages? (I presume C++ is
> covered)
>

C++ is actually somewhat covered. SAX (simple api for xml) is available for
every language. Just about...python, C, perl, Java, maybe more...

xml is becoming more and more ubiquitous. I think the decision just comes down
to... what kind of performance can we expect from it? Programming it is
obviously trivial. How much memory it uses, and size will be the determining
factor in whether we should use libxml, or another xml implementation, or a
home-brew implementation.

>
> Overall, I don't think we'll be pushing the memory too hard...Maybe we
> could set up a test case, just to see how well it performs?
>

Agreed. That's really the only way we can settle this for certain. I'll see
what top reports when testHTML and testSAX are parsing a file 1000 times in a
row. Of course, that will be maxing out the CPU, but what we're going to be
interested in is memory usage.

>
> If the XML idea gets dropped, then if we can keep the clear text for the
> protocol, (optionally SSL'ing it or whatever), that'd keep the clients
> simple.
>
> Matt
>
> -----------------------------------------------------------
> To unsubscribe from this list send a blank message to
> lcdproc-unsubscribe@lists.omnipotent.net



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net