[Expat-discuss] Re: Summary of Pull API thoughts

[Karl Waclawek]

> Karl Waclawek writes:
>  > It looks hard, since even the API itself is statically tied to the
>  > definition of XML_Char.
>  > 
>  > However, you should be able to compile two libraries (XML_Char defined
>  > as char or wchar_t), and dynamically load whichever you need at runtime,
>  > and even switch between them. Why would that not work for you?
> 
> That sounds fairly tedious to me.

But the effort to load a library and set up the pointers to the exported
functions (that's at least how it works in Windows) is a one-time effort
that can be hidden in a re-usable function or class.
 
> Recall that Expat tends to report data in fairly small chunks for
> typical applications.  Even in plain text (PCDATA), Expat breaks data
> at line boundaries.  If you want further control over the amount of
> data reported in the character data callback, limit the amount of data
> passed into Expat for any XML_Parse() or XML_ParseBuffer() call.
> 
> This can be used to an application's advantage, especially if there's
> concern for the amount of memory being consumed.  Compile Expat with
> the appropriate output encoding for your primary audience, and then
> re-encode if necessary in the application logic.  This should be easy
> to implement and allows support for output encodings other than UTF-8
> or UTF-16.

This would work, of course. But maybe on embedded devices CPU cycles
are at a premium. Depends on Chris' circumstances.

Karl