lmi
[Top][All Lists]
Advanced

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

[lmi] [Fwd: Astonishingly, xmlwrapp has vanished; use libxml++ instead?]


From: Greg Chicares
Subject: [lmi] [Fwd: Astonishingly, xmlwrapp has vanished; use libxml++ instead?]
Date: Tue, 09 Aug 2005 16:59:36 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

[On 12 Jul 2005 21:52:33 -0400 I wrote the following email to Vadim.
The new sourceforge.net site for xmlwrapp is still empty today.]

I don't think I was ever able to convince you that it was a good idea
for lmi to depend on a specific ancient version of xmlwrapp. Now, the
situation has become much worse:
  http://pmade.org/software/xmlwrapp/download/xmlwrapp-0.2.0.tar.gz
now redirects you to a page that poses the unwelcome question
  "Where Did Your Software Go?"
There's a link to a sourceforge site that seems to have no content
whatsoever, at least not yet. I have old archives here, and some of
them seem to be preserved online in old gentoo GNU/Linux distributions,
so this isn't an urgent problem today. But we can't continue to depend
on software that vanishes this way.

Would you like to replace it with an alternative library? I think it's
a bad idea to use libxml2 directly--its extremely low-level API makes
that too hard, sort of like writing directly to the ms windows API.
But I suspect that libxml++ may be a good alternative: it's in gnome
  http://ftp.gnome.org/pub/GNOME/sources/libxml++/
it has a freebsd maintainer
  http://www.freshports.org/textproc/libxml++/
and it has a debian maintainer
  http://packages.debian.org/testing/source/libxml++
so it's not going to vanish because one person decides to take it off
his server. And it's LGPL, so we have no licensing issue.

Searching for libxml++ in google gives many more hits than xmlwrapp
gets, which is also a good sign of its vitality.

This application
  http://developer.berlios.de/forum/forum.php?forum_id=11168
"now uses the superior libxml++ for XML parsing rather than xmlwrapp"

This endorsement on the official libxml2 website
  http://xmlsoft.org/python.html
  "Libxml++ seems the most up-to-date C++ bindings for libxml2"
seems significant too. Even better, the libxml++ author seems to
get active support from the libxml2 author:
  http://mail.gnome.org/archives/xml/2002-November/msg00116.html

We have some nasty code in 'ledger_xml_io.cpp' because xmlwrapp
didn't support DOCTYPE; it appears that libxml++ does. Removing
nasty code is usually a Good Thing, of course.

If you know of an even better library, I'd like to hear about it.
Otherwise, I think we should convert to libxml++. At the same time,
we can update to the latest libxml2 (as you already have).

Obviously you already know a lot about xmlwrapp; libxml++'s API
seems remarkably similar. The actual conversion might not be as
hard as testing it. The crucial thing to test is runtime speed.
In file 'xmlwrapp_ex.cpp' you can see that I experimented with
various ways of reading xml files into strings before passing
them to xmlwrapp routine: I had to do that because we often
need to read multiple-megabyte xml files, and users get very
impatient if that doesn't happen instantly.

The only concern I have is that libxml++ seems to use only
UTF-8, and consequently doesn't use std::string
  http://libxmlplusplus.sourceforge.net/docs/manual/html/index.html#id2403496
although it appears interoperable with std::string. Maybe
there's really nothing to worry about there: lmi is really
not useful outside the US because it depends so much on this
country's laws and regulations, so we'll never need anything
beyond U+0080, so all characters we need are equivalent to
7-bit ASCII.

There are several ways this could fail. Maybe it won't be fast
enough. Maybe it lacks some crucial feature of xmlwrapp. Maybe
it's full of nasty defects. Probably the only way to find out
whether it meets our needs is to do all the work.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]