Howdy, <div><br></div><div>"First time caller, long time listener" :-P</div><div><br></div><div>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:</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Iterators could also be great in declaring an outside definition ddl or something imported at runtime, to check x y z.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Failover memcache support without explicit scripting -- thinking of localcache/memcache in a pool similar to how current db_virtual works -- would be extremely handy.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>
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.</div>
<div><br></div><div>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".</div>
<div><br>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.</div><div><br></div><div><br></div><div>-Bobby Smith</div><div>aidanna on Freenodej</div>