On Monday 11 October 2010, Juha Heinanen wrote:
One reason for developing the module was that there were no dialplan and htable available during the time we developed it. :-) Another reason is that its in this form conceptionally easier to understand, maintain and use for the (limited) requirements we've had for it so far. This was also the reason for the choice of a O(n) function for the lookup.
ok, but when you introduced matrix module to sr, htable module was already there and it looks to me that matrix module provides a subset of htable's functionality and implements that subset in a slower way.
in general, i don't think that it is a good idea to add modules that do not provide any new functionality or better performance as compared to existing modules. what is sr policy on this or is there any?
Hello Juha,
well, in general i agree to you. We discussed this before with Daniel some time ago. So far he had no objections against it that time. It should be stable, in an internal version its in production use since years and its maintained by us. If somebody don't need the features that htable provides and its looking for something more simple (like just an array), then maybe he find the module as useful as we do.
In other areas we also have overlapping functionalies with different datastructures, like in RURI prefix rewriting: dispatcher (linked list), lcr (hash table), cr (trie), mtree (tree?) and also drouting (trie), which was added not that long ago.
Cheers,
Henning