[Serdev] Re: [Serusers] Re: usrloc loading

[Martin Hoffmann]

Jiri Kuthan wrote:
> 
> I think the feature you are suggesting (cancel-if-it-takes-too-long for whatever
> reason) could be reasonable self-recovery tool. I think that in addition to that
> going through the code case-by-case is unavoidable so that we dont have to
> 503 unnecessarily.

True. However, the strength of SER (and IMHO the main reason for its success)
is that you can easily adapt it to all sorts of weird stuff through the
routing script (We could start a section on the web page where people
can post the most evil things they did with subst()).

That's why I would like to give the option to do these things to the
script writer and not set too much in stone. (Which sort of leads to
another possible point for improvement: the module interface. If you
like, I can elaborate a bit in another mail.)

> >> well -- aliases via usrloc was kind of temporary solution which stayed
> >> longer than planned :-)
> >
> >I actually like it. 
> 
> That's embarassing to me :-) I consider it a great feature not to have it any
> more. One of the reasons is that aliases are actually provisoned data whereas
> usrloc is kind of temporary data (or session data, web folks could say). In
> highly optimized systems you may use completely different data processing
> techniques. Then it is unfortunate if the provisoned alias data is treated 
> using data tools for temporary data.

>From a back-office point of view, alias is just another table (except,
of course, for the caching). I do not know enough about database design
to decide which approach is better, stuffing everything into one attribute-
value table or having dedicated tables specifically designed for the
purpose. I suspect your friendly DBA would rather have the latter.

> >More so, I recommend using usrloc for call
> >forwarding as well. The advantage over AVPs is that you can have more
> >than one address to forward to (aka parallel hunting).
> 
> I think you can have it with AVPs as well.

Damn. It is really time to start working with SER 0.10. If only the day
had 36 hours.

[...]

On the next sections I think we agree to partly disagree. It comes down to:

> Again -- I think this is interesting what-if academic conversation but if you think there
> is some design error which precludes some working scenario, highlite it for me.

I think I did. IMHO forcing users to use the usrloc cache is wrong.

Where this actually leads to is this: Will SER eventually have a
none-caching database mode for usrloc? If yes, I am perfectly happy. If
not, I have to consider takeing over maintainership of usrloc-cl since
Andreas apparently jumped ship.

Best regards,
Martin