On Sat, 2004-01-10 at 17:10, Tim M�ller wrote: > On Saturday 10 January 2004 10:58, Olexiy Avramchenko wrote: > > > As for size issues: I'm afraid that Glib's markup stuff doesn't handle > > compressed xml files, > > like libxml2 does. For example: I have ~600KB xml for my current > > project, gzipped it's about ~36KB. > > That's a good point. I didn't know it was possible to use gzipped XML files > with libglade, and it certainly makes sense. > > However, in that case I'd just add a dependency to libz (which is already > there anyway when using Gtk+), and decompress the file/buffer in libglade > using libz before feeding it to the GMarkupParser.
I agree that gzip'ed xml files are not a compelling reason for using libxml2 however Glade uses a full XML spec and is not just a simple configuration script reader. Questions to ask are is Glade going to use advanced XML functionality in the future? How about embedding SVG graphics for icons? Is moving to GMarkup really gain us anything or is it just a hunch that since it is not a complicated a lib nor as big this means instant meaningful gains? Is startup noticeably any faster with GMarkup? Can we perhaps have GMarkup as a compile time option for embedded uses instead of betting the farm on it? Is GMarkup going to be as well maintained as libxml2 is today? Historically libxml was used because GMarkup had not been implemented yet and libxml was the standard. To rip that out now might not give us all that much benefit. Comparisons need to be made of each case. I personally don't think moving to GMarkup is a good idea just because it is was setup to be just a configuration reading library. Here is a blurb from the docs: The "GMarkup" parser is intended to parse a simple markup format that's a subset of XML. This is a small, efficient, easy-to-use parser. It should not be used if you expect to interoperate with other applications generating full-scale XML. However, it's very useful for application data files, config files, etc. where you know your application will be the only one writing the file. Full-scale XML parsers should be able to parse the subset used by GMarkup, so you can easily migrate to full-scale XML at a later time if the need arises. If size of the libxml2 library is an issue have you tried compiling with some features turned off? This is not to discourage you from porting to GMarkup. I just think for such an important piece on the desktop we need to stick to standards just to give us room to expand in the future. I guess I would say the best thing to do is try to integrate GMarkup as a compile time option where others can go and benchmark the two approaches to see which is best. -- J5 _______________________________________________ Glade-devel maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/glade-devel
