From: Daniel Veillard (Daniel.Veillard@w3.org)
Date: Sat Oct 14 2000 - 13:06:34 EDT
On Sat, Oct 14, 2000 at 03:39:26PM +0000, Bjorn Reese wrote:
>
> Daniel Veillard wrote:
>
> > - this introduce a binary incompatible change, some data
> > structures are changed and that a first thing I will have
> > to correct
>
> Why is binary compatibility an issue?
Because I distribute RPM binaries, this is something I got troubles
with in the past and I have learnt the hard way to avoid this :-\,
adding to a structure is no problem but removing can led to problems.
> > - an hash table only makes sense if the pool of object is
> > clearly larger than the number of entries, and whatever how I
> > turn the problem, I don't see how i would need to register
> > 250 functions, if you have such an use case please enlighten me
>
> Let me reiterate, the number is arbitrarily chosen. Change it to
> whatever pleases you.
Okay I was wondering if you had a specific need for a large number
of functions or variables, that's all !
> > - the function used to compute the hash looks rather costly
> > you have a multiply and an add per char in the string, I
> > usually simply compute the sum of all chars in the string
> > which for a 256 hash size should be good enough.
>
> I use a standard hash key computation algorithm. If you disapprove
> of it, change it (if you feel the distribution of your algorithm is
> good enough). I don't see the issue here.
Okay
> > - the overall memory used for storing the hash table seems a
> > bit inappropriate in that specific case of the few XPath
> > functions (but tiny compare to a DOM tree size and other use
> > of hash tables in libxml).
>
> As you mention, the size of the hash table is neglible compared to
> the size of the parse tree. We are talking peanuts here. Again, I
> don't see the issue here.
Okay
> > - adding a new header and C file would only really make sense if
> > those were reused in multiple places.
> >
> > I think integrating the patch as is is a bit problematic right now.
> > But I think it does make sense to try to reuse it to make it the
> > hash table interfaces used in other parts as well (entities, element/
> > attributes/notations declarations, and the XPath registry).
>
> This was exactly the reason why I made the hash functions generic,
> and put them in separate files (well, this and the good software
> engineering practice of modulability).
Okay
> > I hope that you won't take offense if I don't integrate it for
> > 2.2.5, I think I will reuse it but as explained in a larger context :-)
>
> Well, I was only trying to be helpful.
Well, it is helpful !
> I do not take personal
> offence, but I will, in all likelihood, be more cautious with
> future submissions.
I didn't want to discourage you, I just raised a few issues.
I was wondering if any of those point was important to you, especially
if you really needed hash tables in next release or if you could wait
a bit until completely integrated.
Daniel
-- Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks : Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux XML libxml WWW Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | Gnome rpm2html rpmfind http://www.w3.org/People/all#veillard%40w3.org | RPM badminton Kaffe ---- Message from the list xml@rpmfind.net Archived at : http://xmlsoft.org/messages/ to unsubscribe: echo "unsubscribe xml" | mail majordomo@rpmfind.net
This archive was generated by hypermail 2b29 : Sat Oct 14 2000 - 13:43:19 EDT