Re: [xml-bindings] xmlCore (was: Let's start)



On Thu, Feb 07, 2002 at 10:27:00AM +0100, Petr Kozelka wrote:
> Hello Daniel,
> 
> inspirated by this:
> 
> >      of names and attributes in a similar way. For examples in the
> >      current python bindings I have the following hierarchy:
> >        xmlCore
> >            xmlNode
> >        xmlDoc
> 
> but maybe a bit off-topic:
> did you ever think about having a separate structure containing all, and only,
> the members common to all node types, and having these referenced in the node
> struct declarations as a member ? Then it would be possible to specify
> explicitly, for each API function, if it handles any node, or just a specific
> node type.
> IOW, it would mirror the role of "Node" defined by DOM.

  Yes this was suggested already,

> I am aware that this would mean a lot of changes to the current API (thus
> impossible ATM), however then it would a bit more intuitive... in fact, when I
> started to learn the API, I was quite confused by the xmlNode struct; I did
> believe that it is the common part, and that xmlElement is element node, etc. Of
> course: because learning DOM spec preceded ;-)
> I am sure I was not the only one thinking this way...

  Well of course API wise changing this is not possible. But there is another
aspect that is very important: memory allocation ! Basically under such
a design allocating the node requires to allocate 2 blocks, and deallocation
also requires to free 2 blocks instead of one in the current design. Of course
this point should be balanced with the other allocations needed like the
node name, content, etc. but currently when profiling the parser and
bulding a tree, the allocations function are the ones taking the most time
(and Linux memory allocator tends to be fast compared to other implementations).

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/



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