11 Oct
2010
11 Oct
'10
3:44 p.m.
On Monday 11 October 2010, Juha Heinanen wrote:
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
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?