Re: [xml] Character encodng cleanup

On Sat, Jul 19, 2003 at 01:27:06PM +0200, Peter Jacobi wrote:
Hi Daniel, All,

As already discussed, using the xmlCharEncoding enum must go
away, as the enum is always in danger of not covering an exotic

So far, work proceeds relatively painless, but look into the
usage pattern in xmlIO.c: 

xmlAllocParserInputBuffer and related functions pass around
the current encoding as xmlCharEncoding enum, so two
questions arise:

1) Must these versions of the functions be kept for API


I fear yes, it's a major PITA, that libxml2 make
nearly every internal detail visible?

  libxml2 makes a lot of internal detail visible. It's a pain
for refactoring but a blessing when programming.

2) Should the replacement functions pass the encoding
as encoding name or as xmlCharEncodingHandlerPtr?

As other functions in xmlIO.c have decided to use
xmlCharEncodingHandlerPtr, I would prefer following
this trend.

  Well, point is that an xmlCharEncoding has no state,
a string doesn't either. On the other hand an xmlCharEncodingHandlerPtr
is in the general case stateful. Replacing stateless parameters with
stateful parameters must be looked at, it makes a serious difference.
So I would not state a preference, each case (and coherency) should be


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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