[OpenSIPS-Users] openSIPS 2.0 design, a couple of questions / thoughts

[Bobby Smith]

Howdy,

"First time caller, long time listener" :-P

I've just read over the openSIPS 2.0 design after the cluecon presentation
and was both impressed and excited about the future.  But there were a
couple of concerns and suggestions I'd like to bring up that involves my day
to day job:

a) True support for an iterator construct.  The ability to iterative over a
keyset could expand configuration capabilities beyond where they are now.
 For example, getting a localcache hit for a pipe delimited key, let me
assemble that into some sort of avp that's array like and easy to iterate
over.  We kind of hack this together now that there's a memcache api, but it
would be nice to have some sort of construct in core.

I can see this being valuable over things like multiple
src_ip==XXX.XXX.XXX.XXX statements in a t_relay scenario, without having
to over complicate using dispatcher or drouting (which I love) to configure
this.

Iterators could also be great in declaring an outside definition ddl or
something imported at runtime, to check x y z.

Also, less domains, more aliases.  Example:  I have an entire group of users
that register via an "account", because of this doing alias=domain isn't the
greatest, if i could do regex inside the alias statement and have it load
all of the applicable values, that would be really awesome.

The documentation on drouting and auth needs to be improved slightly --
those are two areas that people seem to get confused at (if you retain these
constructs).  It took a few days to dive into how auth works, but
afterwards, not so bad.

Failover memcache support without explicit scripting -- thinking of
localcache/memcache in a pool similar to how current db_virtual works --
would be extremely handy.

I'm lookning forward to the being able to script other languages and have
them lex/yacced in, but I honestly feel the syntax of opensips config
scripting feels natural to anyone with a c background.

A c type "struct" might also be beneficial, initialized at script time with
pvar or avps based on request information, where you could directly
reference the struct.

Lastly, I just want to say how much of a joy it's been to work with openSIPS
over the past three years.  You guys have taken a solution that's carrier
worthy and stepped up beyond the challenge, and I'm pretty certain with a
database and string transformations I can do just about anything I want.  I
think one of the biggest steps is making this accessible to the
end-user/administrator.

And you guys really need a dedicated admin tool.  I've used the osipsconsole
(i reverted back to opensipsctl for most), i've used the xmlrpc_MI
interface, and I've used a couple of the other tools out there (the php
admin util, the grails admin util).  All of them are great in theory, and
have great ideas mixed in, but I think for the community there should be a
unified effort to standardize this and offer something prepackaged for
administrating an install -- I think it would remove a ton of the complexity
for those who are getting cold feet over "getting their hands dirty".

Again, thanks for all of the support, the bug fixes, and the IRC
coversations from one of the faster growing VoIP providers in the US.


-Bobby Smith
aidanna on Freenodej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100817/19dab5f9/attachment.htm