Re: [xml] xml diff and patch support -- new node type

[Daniel Veillard <veillard redhat com>]

On Wed, Feb 02, 2005 at 07:27:51AM -0800, Mark Vakoc wrote:
> Basically I needed a queue that can quickly look up nodes in it by a hash value
> that guarantees I can pull out matching entries in the order they were added to
> the queue.  The table may contain multiple matches for the same hash value. 
> Here's the API for it so far:
>
> /*
>  * Hash Multimap
>  */
> XMLPUBFUN xmlHashMultiTablePtr XMLCALL
>                       xmlHashMultiCreate(int size);
> XMLPUBFUN void XMLCALL
>                       xmlHashMultiFree(xmlHashMultiTablePtr table, 
>                                       xmlHashDeallocator f);
> XMLPUBFUN int XMLCALL
>                       xmlHashMultiAddEntry(xmlHashMultiTablePtr table, 
>                                       unsigned long hash, 
>                                       void* userdata);
> XMLPUBFUN xmlHashMultiEntryPtr XMLCALL
>                       xmlHashMultiLookup(xmlHashMultiTablePtr table, 
>                                       unsigned long hash);
> XMLPUBFUN void* XMLCALL
>                       xmlHashMultiGetData(xmlHashMultiEntryPtr entry);
> XMLPUBFUN xmlHashMultiEntryPtr XMLCALL
>                       xmlHashMultiNext(xmlHashMultiEntryPtr entry);
> XMLPUBFUN int XMLCALL
>                       xmlHashMultiSize(xmlHashMultiTablePtr table);
> XMLPUBFUN int XMLCALL
>                       xmlHashMultiRemove(xmlHashMultiTablePtr table, 
>                                       xmlHashMultiEntryPtr entry, 
>                                       xmlHashDeallocator f);

  looks generic enough ! Fine by me, I will double check but first glance it
looks good :-)

> >   Hum, that is annoying. It's gonna break lot of stuff. If such node are
> > never exposed afterward, I suggest to not add it to ElementType.
> >
> > > Just a heads up and want to make sure adding a new value to the
> > xmlElementType
> > > enum is ok before I commit to that.  Should have a patch ready in a week or
> > > two.
> >
> >   I would rather make a #define for the new element type and avoiding 
> > it from escaping the scope of the xmldiff C module.
>
> Ok, I can keep it entirely within the xmldiff module.  I'll just have to remove
> those nodes manually before calling any xmlFreeDoc, no problem.  When I'm done
> I may be able to get away with just storing info into an existing element
> already, though those are filling up.  So far node->_private stores a hash
> value of the subtree rooted at that node, node->extra is used for bitwise
> flags, and node->line is used for relative position of a child.

  Okay, maybe use ->psvi to avoid using _private at all but it's a detail...

  sounds good :-)

Daniel

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