Re: Future

[Alan S. <aj...@fr...>]

> 2.  Fix the documentation to provide more detailed explanation of each
> function.  At present you have to understand the conventions and
> mentally figure out what should be happening.

Amen!  I think I mentioned before that late in the project Doug ditched
my highly technical manual entries (written by a programmer, for
programmers) for the lighter-weight ones you see today, aiming to get
greater acceptance.  I don't think it worked.

> 4.  Think about re-entrant version of the Google version, which
> reduces the overhead in JudyNext having to lookup the key it found
> last time.  The google version stores the internal state so the next
> call can proceed without a full scale lookup from the top.  However it
> does it the wrong way, embedding the state in the array, instead of
> making the client hold it.

Sounds right, and good, to me.

> 5.  Fix the disgusting build system.

Yeah, for that I apologize myself, it was the best I knew how to do at
the time with the tools in hand.  Linux autoconf/etc weren't well known
to us.

> My basic opinion is:  Judy is very well designed.  but it isn't well
> known or used as often as it should be.

Yeah, that's about right I think.  I've always been disappointed that
something so profoundly significant we discovered turned out to be so
hard to embody, explain, share, and put into use.  So it goes.

Cheers,
Alan Silverstein