xml-dev - Re: Storing application state as XML

["Steve Kearon" <stevek@fineline-software.co.uk>]

We went through the same process as you: having used MFC serlialization, XML
sounded like it had various advantages.

We adopted XML, but use an event-driven parser instead of the DOM. This has
the benefits of speed + code size. Being event-driven tends to force you
towards a one-pass process when reading the application state in - but
that's generally a good fit for serializing application state.

We simply stopped callng MFC's open/save CArchive stuff, and called our own
routines.

For input (which must be parsed), we use expat (from James Clark) built in a
DLL with a small C++ wrapper to make life easier. The wrapper class
represents an "add-in" to any class to make it XML-parsing capable. The
wrapper also permits one XML-parsing class to pass responsibility to another
class (ie I maintain a stack of handlers). This facilitates (eg) my <person>
element handler to pass control to a <address> element handler whenever it
spots an address. By and large, one class deals with one element type, but
that's not a hard and fast rule.

For output, we implemeted a simple output stream that formats element names,
formats various types of attributes, converts '<'  to literals, converts
from ANSI to utf8, etc.

Typically, a class name equates to an element, a class data member equates
to an attribute. We haven't (yet) used element content at all. Nothing
religious - it just never seemed appropriate.

When opening a file, we tolerate quite a lot (eg someone could add
attributes/elements that we'll ignore). To conserve file space, we normally
write files in "compact" mode, where only attributes that differ from the
default setting (ie the constructor initialised setting) get saved. This
saves oodles of disk space. A "verbose" mode is also available where
everythig gets saved.

There are alternatives to expat, but expat offers everything we need at
present. An alternate C++ wrapper class can be found at
http://www.oofile.com.au/

I'd be glad to go into details of this stuff (including sharing the code). I
suspect it would make a nice little article for somewhere like
www.codeguru.com, but (like most folk) I can never find the time.

Steve Kearon
FineLine Software

-----Original Message-----
From: Ketil Z Malde <ketil@ii.uib.no>
To: XML-Dev Mailing list <xml-dev@ic.ac.uk>
Date: 17 June 1999 12:06
Subject: Storing application state as XML

>
>Hi,
>
>I must admit I don't have the time to follow this list as diligently
>as I'd like, so it is possible that my questions have been answered
>already.  I'll submit them nevertheless. :-)
>
>We have a rather complex application which stores its state using the
>standard MFC serialize stuff (well, actually a somewhat hacked
>version, but that's beside the point).  Now, this limits our freedom
>in (or at least severely complicates) redesigning internal class
>structure while maintaining backwards file compatibility, and we've
>been pondering an XML format instead.
>
>There are of course other advantages, like accessing the information
>from other applications, or generating HTML and whatnot.
>
>The question is whether this, in general, is a good idea, and whether
>people have done this, and if so, to what degree of success, and by
>what methods.
>
>I can see two ways of doing this:
>
>1) Use a DOM-based document, which can be passed around, much the way
>a CArchive class is, and modifying the Serialize() to fill in the
>relevant nodes in the document tree
>
> or
>
>2) Encapsulating the document (DOM or otherwise) in a separate class,
>which traverses the application's classes and picks whatever
>information is relevant in whatever sequence it desires.
>
>The advantage of model 1 is a structure quite similar to what already
>exists, most of the code base could be left alone, I think.
>
>On the other hand, if our existing classes are well designed, all the
>relevant information should be accessible through the public:
>interfaces, and it should be easier to build the document in a
>flexible way.  E.g. the placement of various information might not be
>obvious from the class' perspective.
>
>So, before we jump the gun, I'd like to hear from people who have done
>this, and are willing to share their experiences, or otherwise
>contribute suggestions and ideas.
>
>Thanks for listening,
>
>-kzm
>--


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)