24 Aug
2009
24 Aug
'09
4:24 p.m.
On 24.08.2009 15:57 Uhr, Iñaki Baz Castillo wrote:
Using RPC interface gives
access to MI commands -- so ser guys are the
first lucky :-). However, let's get back to the root:
- there are modules implementing MI
- there are modules implementing RPC interface
- there are modules implementing none
- there might be modules implementing both
Where to position a module is just a matter of developers. Similar
choise is for regular expressions - use posix or pcre library -
database - use interface v1 or v2 (which has prepared statements
support) - and examples can continue. I see ability to choose a great
feature.
2009/8/24 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
yes, I do, even older, I have a ser 0.9.4 somewhere and no plan to
upgrade it. It has 1 year 4 months without restart.
I am personally aware of companies using Kamailio
with several millions of
subscribers, using kamailio database schema. Also, I am aware of companies
having more or less same level of subscriber base using SER database schema.
All have additional tools for management, integration with third-party
application, a.s.o. Do you think that saying "hey, you were the unlucky
bastard because we are going to drop tomorrow the database schema you are
using" is the solution?
That's right, but I don't expect that migration to SR is a priority
for those companies already using OpenSER/Kamailio. For example, I
know some companies still using OpenSer 1.2.
However, it seems that the idea is that Kamailio/SER
will use SR as
core, but the fact is that SR core uses current Kamailio and SER
modules/features as separate (modules_k, modules_s...).
some modules were moved under "modules" directory. The ones that have
names overlapping and inter-dependencies are going to stay in separate
directories.
Wouldn't make
sense to unify SR code instead of having it splited in K and S?
probably you misunderstood something. The code is unified, but SR has
support to hold modules in more than one directory. Now the structure is
based on origin (again, the reason is name overlapping), but in the
future could be:
modules_presence
modules_db
IIRC, there are over 150 modules all together, so better structuring
might be necessary.
AFAIK
this is the idea for a future, but in the meanwhile I don't fully
understand why SR requires to run right now as it is.
Sure that's a good reason :)
But again you are speaking about Kamailio using SR as core (new and
improved TM module) while I meant SR code itself (which for now is a
mostly separate mix between K and S code instead of an unified
technology).
I don't get it. Maybe you can rephrase/detail what is
misleading/confusing you. The existence of 3 module directories?
Everything is unified, one source repository, one project, if you think
just to SR environment.
What I
don't understand is the reasons to make current SR working with
K and S features/modules compatibility. We don't need a SR working
solution right now (since Kamailio and SER do exist), do we?
Maybe not you, but there are others. I am facing many troubles because of
TCP (also TLS) layer in K which do not happen with SR core - asynchronous
TCP helps a lot.
All (but seas)
are ported.
Perhaps I understand it wrongly, but IMHO the modules will be really
ported when there is a unique MI interface for all of them (instead of
having to use K MI for K modules and S MI for S modules), when there
are just an unique class of pseudovariables (instead of having K and S
pvs)...
Here is only one: config file variables - how they are referred in mails
is a different story, to better indentify and reflex origin, but all can
be used in config file. Actually, the group referred K PVs have classes.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* http://www.asipto.com/