Re: [xslt] libxml3

[Daniel Veillard <veillard redhat com>]

On Wed, May 08, 2002 at 11:20:59AM +0200, Peter Jacobi wrote:
> Hi Daniel,
> 
> I hope you are relaxed enough to speculate about libxml3!

  Started discarding tons of spam, and still trying to sort 
a bunch of annoying things about my personal life, but I can discuss
it now, sure !

> If I remember right, there was already a statement of
> intent, to not expose the xmlNode (et al) structure to
> clients but let the former pointer be an opaque handle.

  To some extent. Libxslt is fast in part because it doesn't
go through a convoluted DOM like API to access the tree.
The goal is to allow building (and if needed garbage collecting)
the tree on access from a different representation (DB, flat file,
etc ... you name it !).

> This inspires my question, whether you may want to
> accept a mega-patch to make the structure opaque
> to (nearly) all of libxml3 itself. So that about 2000 uses
> of "node->next" (et al) would be replaced 
> with "getnext(node)".

  At that point I'm afraid this would be a bit premature, 
however I would be interested in informations about the 
speed penalty this would generate (hey I could be wrong !)

> The default tree implementation can implement these
> as macros, so that nothing changes in that case. But
> we can have plugable tree implementations.

  yup

> Whereas most of the 2000 changes would be rather
> automatic, it would be useful to substitute some
> occurences with more advanced accessors:
> 
> substitute
>     if (cur->next != NULL)
>         cur->next->prev = cur->prev;
>     if (cur->prev != NULL)
>         cur->prev->next = cur->next;
>     cur->next = cur->prev = NULL;
> with
>   unlink (cur)

  Sure :-) some patch review would be good.

> In effect tree.c would be split in a high level
> and a low level part.
> 
> In addition to question "if", there's the
> question "when would be a good point of time"
> to do this.

  that's yet another excellent question. libxml2 must 
keep providing access to next for existing applications,
but the macro trick could fix this an allow a smoothen 
libxml2->libxml3 path,

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/