Re: [xml] Character encodng cleanup

[Daniel Veillard <veillard redhat com>]

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
> encoding.
>
> 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
> compatiBility? 

  yes.

> 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
checked.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/