[sr-dev] about matrix module

[Henning Westerholt]

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