> Have I asked this before? What advantage does using a balanced tree have
> over using a hash table as pertains to CircleMUD? We have a large mostly
> static data set... It seems like we should be able to hash based on any
> number of criteria and get an efficient and easy implementation of the
> world. I don't think we need to be able to walk the data set in order, so
> I can't help but get the feeling trees are a bit overkill.
To tell you the truth, I considered a hash table, but every hash
lookup system I've used seemed to scale...well...poorly. Let's ignore
that for a moment though;
I chose an AVL tree over a hash tree (or b-tree, which was in the
running), mostly because I have less experience with them (not none,
granted, just less). Hashes, which I use quite alot, were getting boring.
What I was really looking at was a less data-centric view of the
..well..data, and more of a data-system view. Or, in simple terms,
abstraction to the point of having insertion,deletion,lookup, and
traversal systems which can be used without intimate knowledge of the
actual pieces of data being used.
The underlying system that performs this doesn't matter to me,
just as long as the progammer who uses it really never has to worry about
it. Avl's aren't that complicated either, and the whole tree mentality
seems - in my mind - to correspond very nicely with the zone based layout
of most text muds.
Because I had already created such a system with a library but am
not allowed to distribute, I just wanted to make it sort of simliar to
reduce work later on.
>
> > If you're wondering why I wrote it, it's because all the good
> > libraries are licenced in such a way as to conflict with
> > CircleMUD/DikuMUD license.
>
> ...if and only if you distribute them in a combined form. The patch to
> CircleMUD would not include any of the GPL'd code (only calls to it).
> The patch is not under the GPL simply because it calls functions in an
> LGPL library and neither is it under the CircleMUD license by virtue of
> its intended use or its eventual combination with CircleMUD. Therefore
> your code is your code, which can be licensed however you wish. Your
> patch is distributed separate libavl (or what have you), the appropriate
> version of libavl is provided on the FTP site for use with your patch,
> someone downloads both, installs both as necessary, and since the
> end-product is not being publically distributed, the GPL/LGPL never kicks
> in on it and we've circumvented the licensing restrictions.
True, regarding the combined forms. I think though, when
discussing the Diku & Circle licenses possibly changing with a few others
who were representing the GPL, there was concern that creation of a patch
involves inclusion of code from the thing being patched in, even if only
2-3 lines used for reference purposes.
It was never made clear, either by gnu, or others what the 'legal'
limit on inclusion of code for reference such as is found in a patch
constitues that patch as a derivitive work and thus covered by the gpl
(and if the licenses were not compatible, it is non-distributable).
This was listed as large source of future contention...so it
doesn't seem so black and white.
It was suggested that the program with incompatible licenceing
should provide an inclusion mechanism so code modules could be
individually distributed and licenced, and I was given several examples of
how this was done (though I don't have them around....).
PjD
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST