Re: [xml] Potential wrong usage of xmlIsID() in tree.c

On Thu, Feb 23, 2006 at 05:48:20PM +0100, Kasimier Buchcik wrote:
Just an idea:
If we want to avoid to many entry-points for the API, and still want
to have the chance to extend the functionalify in the future, then
what about a multi-purpose entry-point, which is adjusted by the
settings of a context:

  Urgh no... it makes code and API ugly and cryptic.

I leaned towards the flag approach as it allowed for the re-use of 
existing functionality with some modification. My take on the flags 
approach was that the library would have its set of defaults it used for 
behavior. If flags were modified by a developer then they should know 
what they are doing and handle/resolve any bugs found. It would also 
allow additional flags to be defined that possibly could be used in the 
event of future scenarios not yet run into. It's not that I'm against 
adding the DOM functionality, I just worry that as we push the envelope 
and specs and technologies continue to evolve, we may end up back at 
this same point again due to some different issue and have to start this 
process all over again. My preference would be to not have to always 
create new functionality if it is possible to re-use existing to some 

If the decision is to just create specific DOM functionality, would it 
make sense to move it all to its own file? The tree.c file is already 
quite large to sort through everything imo.


I think that moving to an own file would be good. We've done that with
the functions in xmlstring.c as well, IIRC.

  yes, this may make sense, this could also be configured out. I like this
but try to not duplicate too much code. The resulting code size does matter
both from a memory runtime standpoint and from a maintainance one.


Daniel Veillard      | Red Hat
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]