> 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

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel

Reply via email to