<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.12.1">
</HEAD>
<BODY>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">> For people interested in looking at what SER does, this message led me </FONT>
<FONT COLOR="#000000">> to take a look a SER 2.0 documentation and bits of code, and it is not </FONT>
<FONT COLOR="#000000">> immediatly evident that they are taking a radically different route </FONT>
<FONT COLOR="#000000">> ... they also improved timer granularity (down to a resolution of 62.5 </FONT>
<FONT COLOR="#000000">> ms).</FONT>
<FONT COLOR="#000000">openser 1.2 has a granularity of milliseconds - you can adjust it as you </FONT>
<FONT COLOR="#000000">want, based on your system requirements. Default value is of 100 </FONT>
<FONT COLOR="#000000">milliseconds - the tests showed it is enough for high quality </FONT>
<FONT COLOR="#000000">retransmissions without any performance penalties.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
I was not arguing, just quoting facts.<BR>
However it is good you clarify this for OpenSER, some people might have though my statement was implying SER is "better" or "worse" in this respect. But this is not the case, things are just different <IMG SRC="cid:1175265655.30774.36.camel@localhost.localdomain" ALIGN="middle" ALT=":-)" BORDER="0"><BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">> They also are currently developping a very interesting module called </FONT>
<FONT COLOR="#000000">> "timer", which provides the ability to set timers on-the-fly, with </FONT>
<FONT COLOR="#000000">> callback implemented as routes called when the custom timers fire. </FONT>
<FONT COLOR="#000000">> This seems pretty simple in their model, the timer module being only </FONT>
<FONT COLOR="#000000">> 408 lines long (but I can't tell if this works already or not).</FONT>
<FONT COLOR="#000000">I agree with you, there are a lot of thinks you can build, but the </FONT>
<FONT COLOR="#000000">question is about their importance (as usage). as you know, we want to </FONT>
<FONT COLOR="#000000">focus more one the hot topics (things really needed) and to avoid </FONT>
<FONT COLOR="#000000">wasting resources for thinks not needed at that moment.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
In fact, I'd say that such module would be great if someone needs it and want to code and contribute it <IMG SRC="cid:1175265655.30774.36.camel@localhost.localdomain" ALIGN="middle" ALT=":-)" BORDER="0"> <BR>
Still I found the idea interesting, but only because I have _features_ in the back of my mind ... <BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> An other puzzling fact is that SER's implementation of timers in tm </FONT>
<FONT COLOR="#000000">> module is about half the size as OpenSER's .... I'm not sure we can </FONT>
<FONT COLOR="#000000">> infer anything from this fact, still it made me curious.</FONT>
<FONT COLOR="#000000">well...size does not matter ;) - also the code structuring may differ. </FONT>
<FONT COLOR="#000000">and so far I found no relation between size an quality for code :)</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
Right. But sometimes, with an identical functionnal-set, length of code (with a ponderation for code density per line) might be an indicator of added complexity. But this can not really be generalized, typical counter-example being language idioms, often very compact but more error-prone and less readable in general.<BR>
<BR>
Regards,<BR>
Jerome<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>