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
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
