User Tools

Site Tools


Chat log IRC Devel Meeting - 2016-04-21

introductions and chat

miconda: going to start in few minutes …
marrold: o/
Guest55581: Hiabalashov: Felicitations!
eschmidbauer: hi
miconda: draft of the agenda is here:
miconda: we wait few more minutes, maybe oej-mobile can get at the desk
miconda: anything else to add to agenda?
drLester: hi
miconda: list here the topics
abalashov: The new Spiritual Technology module? :)
eschmidbauer-mbp: we have written a new module
miconda: that’s a whole meeting by itself, I let it for you to organize
eschmidbauer-mbp: it's in testing
miconda: eschmidbauer-mbp: nice, waiting for the pull request
eschmidbauer-mbp: it's the NSQ version of kazoo's module
miconda: what’s about … I think you told me some bits
miconda: so just a connector, without kazoo specific features
eschmidbauer-mbp: connect to NSQ and receive messages. just like the kazoo module, it executes event routes based on the json message received
oej-mobile: What is nsq
eschmidbauer-mbp: message queue
– oej-mobile walking
abalashov: It's probably a whole topic unto itself, but in my humble opinion, there should be a generic AMQP connector module without Kazoo-specific features.
abalashov: Along the same premise.
oej-mobile: We may Consider a generic approach
eschmidbauer-mbp: the only thing kazoo specific about the kazoo module is the name kazoo everywhere
abalashov: The Kamailio project is not and should not be responsible for forward-porting and maintaining a module that is essentially an element of a single third-party system, and the Kazoo AMQP module is not useful without it.
abalashov: eschmidbauer-mbp: No, the Kazoo module is not a complete generic AMQP connector. It's designed to talk to Kazoo.
miconda: eschmidbauer-mbp: kazoo does some presence tricks
eschmidbauer-mbp: it's not necessarily designed to talk with Kazoo
eschmidbauer-mbp: it's designed to talk with rabbitmq
abalashov: Well, yes and no.
miconda: eschmidbauer-mbp: but besides that can be used as connector
abalashov: It is designed to talk to RabbitMQ, but in a way that is highly Kazoo-oriented, is how I'd put it.
eschmidbauer-mbp: you can certainly use kazoo module without kazoo platform
miconda: i think that pua module set to 0 turns off all the presence interactions
eschmidbauer-mbp: the module is really designed to control presence via message queue
miconda: oej-mobile is going to be soon oej-pstn …
– abalashov grins
abalashov: eschmidbauer-mbp: Right – and it seems to me that is not the same as a generic AMQP connector.
abalashov: eschmidbauer-mbp: The latter of which would be more useful.
eschmidbauer-mbp: i agree.. it's not generic
– oej-mobile oej-isdn
abalashov: Yep. So, the question is, why is the Kamailio project badly in need of a module that more or less performs a specific function within Kazoo?
eschmidbauer-mbp: and im not here to defend mod kazoo. i just see the usefulness of it *without* kazoo platform
eschmidbauer-mbp: you can control presence via mod kazoo + rabbitmq without using kazoo platform at all
abalashov: Talking to AMQP is of course very useful. I think it should be implemented generically. If I could just find the time… I've been meaning to contribute.
eschmidbauer-mbp: it should really be called presence_rabbitmq or something like that
abalashov: Right, I think what I'm saying is that a generic AMQP connector that doesn't do presence per se would be most useful.
eschmidbauer-mbp: right… essentially the module receives json messages from rabbitmq and executes eventroutes
eschmidbauer-mbp: they have eventroutes which update presence from the json
abalashov: But in general, the Kazoo module strikes me as something analogous to creating some sort of RDBM/SQL DB module that is designed to implement some small subset of a specific product/service and that is complementary to that product.
eschmidbauer-mbp: but you could use it to do anything that an event route is capable of
abalashov: Like, in principle, you could use it as a transport for generic DB interactions, but it's very obviously not intended for that.
abalashov: It's more of a side effect.
– oej back in the office
miconda: eschmidbauer-mbp: - so there is a config option to turn off those internal tricks with pua, which should be documented
abalashov: Sounds like we have a quorum. A call to order then?
miconda: anyhow
eschmidbauer-mbp: yeah. sorry to divert
miconda: looks like we can start …
miconda: waiting for eschmidbauer-mbp to make a pull request to merge his nsq module
miconda: till then, let’s start the discussion here
miconda: —— main open issues

Main Open Issues

miconda: anyone aware of anything critical?
miconda: not reported or reported but no reaction …
abalashov: One of the amazing virtues of your project leadership is that this seldom happens. :-)
qxork: =)
miconda: :-)
abalashov: I've never seen such a high response / acknowledgment rate in any other FOSS project I've been involved with. Hat tip.
oej: Agree!
qxork: I had a critical issue resolved in less than 24 hours I think. Couldn't be happier.
miconda: thanks, I like sleeping during the night, so if it an issue, it’s better to be fixed before someone calls me :-)
drLester: the biggest issue I'm seeing now it's the crash of cnxcc module
abalashov: (All meetings must begin with praise of the leadership … this is a Soviet custom.)
drLester: biggest for me because I'm using it :)
miconda: drLester: yep, cnxcc is sort of not properly maintained
oej: Found a deadlock in usrloc/registrar today
eschmidbauer-mbp: +1
miconda: its main developer is not much active
abalashov: miconda: Has the author moved onto other pastures employment-wise?
miconda: perhaps I should try to check it a bit, although I am not using it
miconda: abalashov: he started a startup on webrtc
drLester: since I worked a little on it recently (I'm Federico) I had a look on the dump and finally I can reproduce the crash
abalashov: Ah.
miconda: :-)
miconda: drLester: Federico from tsilo?
drLester: but looks like the whole data structures are corrupted
abalashov: Unfortunately, this is the reality with a lot of the modules; someone was employed/sponsored by a company to write it, but then they move on, and there's just no further maintenance from them. It's probably an unavoidable fact of life in the entire FOSS world.
drLester: yes that's me :)
miconda: abalashov: true, I don’t have much time for all the stalled modules
abalashov: No, and your attention can't grow in scope forever and ever.
miconda: at some point we need to move some to obsolete
linuxmaniac: this is life, if nobody care, just kill it
abalashov: It has led me to the thought that perhaps we need “core maintained modules that are serious” and a kind of kamailio-contrib universe separate from that…
miconda: already thinking of those reminiscent ser modules prefixed with uid_*
miconda: cnxcc is not a bad one, but quite useful, just that I never got to use it
oej: I think it's a good idea to have a end-of-life process
qxork: sometimes you have to cut weight to move forward
miconda: i try to avoid charging per minute :-)
abalashov: If for no other reason than to manage your workload better. You can't maintain an ever-expanding universe of third-party contributions of varying quality and maintenance commitment, which implement features you may not be especially familiar with or enthusiastic about, etc.
drLester: yes, cnxcc can be very useful to provide call control without he need of having a diameter server
linuxmaniac: if the maintainer doesn't respond… and nobody steps up, we should move it to obsolete
drLester: I'm trying to get into the internals and I'd be happy to try to maitain it
abalashov: I don't think it's a question of whether the module is useful. We just have hundreds of modules, at least some of which are not really being seriously maintained, but are all endorsed on an equal level in the modules list & docs.
drLester: agree
linuxmaniac: the only thing they have to do is not fail to build
miconda: ok — so cnxcc needs some attention, maybe we can hammer it if we manage to get to a face to face devel session later this year (proposed by oej , to be discussed later today)
abalashov: My thinking is that there should be a smaller subset of core modules that are part of active project maintenance and then some sort of -contrib world, but that's just me.
abalashov: linuxmaniac: To me, that's not a very high standard. It can compile cleanly and yet be broken. :-)
linuxmaniac: that is what we have nowe
linuxmaniac: now
miconda: yes. from project point of view, that’s what we have now
linuxmaniac: I'm just saying what is happening right now
– abalashov nods
miconda: and maybe with addition of some testing framework we can add some more selective rules
miconda: to be sure it loads, etc…
oej: We may also want to have a list of current maintainers, like who's bothering with stuff like kazoo, carrier etc
linuxmaniac: that is the point, right now we don't now if a module works
oej: Stuff that's produced by one company and fine so long as they maintain it
abalashov: But then what happens is a year later someone shows up on the list and is like, “WTF? Why doesn't the DogWalk module work, why is the documentation out of date, and why am I running out of SHM after 2 minutes?”
oej: ANd some informal maintainers, like I've been banging my head against the snmp module
oej: I think the list is in miconda's head, but that we need to export it from there
abalashov: And most of the users and developers think . o 0 ( “The DogWalk module? Oh… I guess we have one.” )
miconda: there is a wiki page for contributors/developers
linuxmaniac: the git log is a good list
linuxmaniac: git log – module/xxxx
linuxmaniac: until we have some kind of test is quite difficult to know what is broken
– oej goes looking at the DogWalk README. It is not up to standards.
miconda: to conclude — if someone wants to build a wiki page and add *wanted* maintainers to some of the modules that don’t look active, then we can try to find some
abalashov: Fair enough. I didn't mean to derail the conversation.
tuxd00d: Should each model be “certified” for each core version by its maintainers?
tuxd00d: Module*
abalashov: linuxmaniac: I'm not so much concerned with automated testing of lots of exotic modules for niche functionality, just that they all receive tender love and care by someone regularly.
oej: Well, they need to be active at some point. We have the issue with the SEAS module
abalashov: oej: As far as I can tell the SNMP module is largely useless, although there remains a great deal of enthusiasm for monitoring via SNMP since so many traditional NMSs use it.
oej: side-note: We should be able to load as many modules as possible in a running kamailio. I have a lot of crashes trying
sipidronov: I thought we had some plans about CI testing
oej: abalashov: let's discuss snmp later then, I'm open for input
miconda: oej: no open issues on that
oej: You closed them all!!!! I will try again and open a lot more… he he.
miconda: sipidronov: yes, there are many plans :-) — important is to get some actions
sipidronov: =) oh, I see
oej: Let's have a competition: The one with a kamailio with most loaded modules running at kamailio-world gets a beer.
miconda: deal
sipidronov: Cause we could have not only source code contributed, but CI tests as well
drLester: just loaded or used to?
miconda: oej: to clarify - like loading the module only
oej: Let's start with loaded in an active kamailio
miconda: and setting the mandatory params
oej: Some stuff just crash there
oej: right.
abalashov: From a philosophical point of view this seems unreasonable; not all modules are created equal. When someone tells me that they have long Kamailio uptime, I tell them that what is important is not uptime, but whether the proxy was processing _good stuff_.
abalashov: The same applies to modules.
oej: And later on documenting which parameters are mandatory in the README
oej: Yes, but I discovered a lot of crashes whcih we should not have when loading modules. I am not saying anyone should run that way (like asterisk autoload bleeeeh) but we can detect a lot of crashes this way
linuxmaniac: oej: parameters need sane defaults
oej: define “sane”
oej: Let's get back on track. If we have one.
abalashov: oej: We do!
oej: We need a meeting for open discussions and some food
oej: But that's later on the agenda
linuxmaniac: so.. no open issues
miconda: ok, so if we are done with the critical issues, then next one

xmlrpc return code

miconda: ycaner is involved in it
ycaner: hello
linuxmaniac: return code?? should be http 4XX doesn't it?
miconda: to summarize: the complain is that some rpc comands don’t return data
miconda: specially the reload ones
ycaner: http return code and rpc return code is different in my wiev
miconda: linuxmaniac: if there is an error, it will be a different response document
miconda: with a rpc error code
linuxmaniac: then, I see no problem
ycaner: in xml spec there isnt any explain about when success
linuxmaniac: reload… 200 ok
miconda: however, my interpretation of rpc is that if there is no data to be used, nothing should be returned
miconda: and then is a baser 200ok http code plus the body with empty rpc data
oej: There is a religous war in the API world about this - should the http response reflect the aPI response or not?
oej: In most cases HTTP response indicates if an app runs or not, and the data returned indicates if the app returns a failure
miconda: oej: I think rpc has also large reply code numbers
oej: so a 200 OK with a failure response in xmlrpc is fine
abalashov: oej: I thought the general thinking is that the HTTP response code should indicate a failure, but merely empty data or zero affected entities or whatever should just return an empty set.
oej: There is a spec for xmlrpc by dave winer somewhere
miconda: well, what ycaner wanted (a push request is also open), was to add to data of the rpc response the “200 ok“
qxork: 200 ok would indicate api is ok, and returned value
miconda: right now “kamcmd dispatcher.reload” has no data in response
qxork: to me anything else would be api error and not error of module/data
miconda: all is fine, nothing is needs to be returned
oej: XMLrpc specification says “Response format
oej: Unless there's a lower-level error, always return 200 OK.
miconda: and I think that are the specs saying
derrickb: \join #sems
miconda: in my opinion would be better for the rpc client tool to present more info
miconda: e.g., all was ok
miconda: rather than making the server side callback to write “200 ok” in the body of the response
miconda: because “200 ok” is not a data returned due to running the rpc callback
oej: There are a few xmlrpc apps for OS/X I have used for testing stuff
miconda: adding the response code to the rpc data body means that for each command returning useful data, some other field needs to be there with the code (e.g., for dispatcher.dump, along with the records from dispatcher memory have the “200 ok”)
miconda: so far everything works fine with many xmlrpc clients
qxork: isn't that required for being in xml spec?
miconda: in xmlrpc specs it saying only the error code
miconda: if no error element is present, then it was a success
qxork: and return 200 ok.
miconda: 200ok is the http return code that can be also for an rpc execution error
miconda: rpc execution error has the xml doc like:
miconda: HTTP/1.1 200 OK
miconda: Connection: close
miconda: Content-Length: 426
miconda: Content-Type: text/xml
miconda: Date: Fri, 17 Jul 1998 19:55:02 GMT
miconda: Server: UserLand Frontier/5.1.2-WinNT
miconda: <?xml version=“1.0”?>
miconda: <methodResponse>
miconda: <fault>
miconda: <value>
miconda: <struct>
miconda: <member>
miconda: <name>faultCode</name>
miconda: <value><int>4</int></value>
miconda: </member>
miconda: <member>
miconda: <name>faultString</name>
miconda: <value><string>Too many parameters.</string></value>
miconda: </member>
miconda: </struct>
miconda: </value>
miconda: </fault>
miconda: </methodResponse>
miconda: an ok handling is like:
miconda: HTTP/1.1 200 OK
miconda: Connection: close
miconda: Content-Length: 158
miconda: Content-Type: text/xml
miconda: Date: Fri, 17 Jul 1998 19:55:08 GMT
miconda: Server: UserLand Frontier/5.1.2-WinNT
miconda: <?xml version=“1.0”?>
miconda: <methodResponse>
miconda: <params>
miconda: <param>
miconda: <value><string>South Dakota</string></value>
miconda: </param>
miconda: </params>
miconda: </methodResponse>
miconda: So, when there is no value to be returned, practically the xml looks like:
miconda: <?xml version=“1.0”?>
miconda: <methodResponse>
miconda: <params>
miconda: <param>
miconda: </param>
miconda: </params>
miconda: </methodResponse>
miconda: the pull request want to change that into:
miconda: <?xml version=“1.0”?>
miconda: <methodResponse>
miconda: <params>
miconda: <param>
miconda: <value><string>200 ok</string></value>
miconda: </param>
miconda: </params>
miconda: </methodResponse>
linuxmaniac: but there is no <fault> so that means it is already OK
miconda: yes
linuxmaniac: why we need a value?
linuxmaniac: I don't see it
miconda: ycaner may comment more why he wants it
qxork: shouldn't it just be:
miconda: for me it is working fine as it is now
linuxmaniac: +1
ycaner: well , there is different between fault and empty response
qxork: HTTP/1.1 200 OK
linuxmaniac: pastebin!!!! please
ycaner: fault and succes returns HTTP/1.1 200 OK
ycaner: both of them
qxork: HTTP/1.1 200 OK Connection: close Content-Length: 158 Content-Type: text/xml Date: Fri, 17 Jul 1998 19:55:08 GMT Server: UserLand Frontier/5.1.2-WinNT <?xml version=“1.0”?> <methodResponse> <params> <param> </param> </params> </methodResponse>
linuxmaniac: but the fault has a <fault>
linuxmaniac: so that is your difference
qxork: is it a fault or just no data?
ycaner: empty xml makes a void without result
miconda: qxork: is no data
miconda: qxork: successful execution, no data returned
ycaner: that means when developers send a request always wait a response what happend
ycaner: and it returns empty xml so that there is no info about it
miconda: ycaner: but there is a response, just no data
miconda: qxork: from where did you take that example?
miconda: it is same format as we return for no data response
qxork: I combined what you put with the requirement of 200 OK
Kaian: methodResponse + params = success, methodResponse + fault = failure
ycaner: and if it will be added , it will be useful that realtime reload
miconda: ycaner: maybe that info belongs to the tool (e.g., kamcmd/kamctl)
miconda: not to the implementation of the rpc method
miconda: Kaian: yes, I guess that is the right summary for interpreting the execution
miconda: anyhow, to conclude here
miconda: if there is anything new, should be discussed on the mainling list
ycaner: well after reload all kamailio with new cfg like asterisk on rpc , it need returns some data about it
miconda: otherwise, a proposal to make it coherent over all rpc commands and be configurable should be advanced, then discussed
miconda: ycaner: but you can return further from your app
ycaner: which one of them is reloaded correct or not
Kaian: correct reload is implicit in the format of the response
miconda: it is reloaded correct if it is: methodResponse + params
miconda: it was no ‘fault’, then the operation was succesful
ycaner: when gets empty xml or no fault result
miconda: so let’s discuss on mailing list if there is anything new
ycaner: it is correct
ycaner: it si right
miconda: already one hour gone, many stuff still to discuss
linuxmaniac: next point please
miconda: ycaner: yes - methodResponse + params (empty content) is successful execution of the command

rpm packages

miconda: — — rpm packages
miconda: just again to see if anyone wants to spend some time on taking care of them
miconda: if no one here, then next topic

servers maintenance

miconda: — — servers maintenance
miconda: needs an upgrade to jessie
linuxmaniac: I can help with that
miconda: wondering if anyone knows something that we should be careful regarding exim and mailman
miconda: linuxmaniac: ok, thanks
miconda: i will have voztelecom making a full backup before
linuxmaniac: please
linuxmaniac: I will destroy it
linuxmaniac: :-P
miconda: :-)
qxork: I can help with upgrade as well and store backup on lod
miconda: it is a VM :-)
miconda: qxork: important things are backed up on lod
linuxmaniac: time to migrate to postfix ??
abalashov: I run Exim and Mailman.
miconda: linuxmaniac: not sure what that involves — we can discus it
abalashov: Will always run Exim, greatly prefer it.
abalashov: Host several mailing lists, two of which are large.
qxork: prefer postfix
abalashov: Exim is a “folk tradition” for me, I've been using it since the late 1990s.
qxork: but if it aint broke, don't fix it
linuxmaniac: exim configs are quite complex
miconda: next one about maintenance was to see how many are using mobile devices to browse the
qxork: almost never mobile
miconda: i was thinking of putting a responsie theme there for wordpress
qxork: but, responsive should be done anyway
qxork: (for seo)
abalashov: miconda: I think this is a good idea. It's reasonable to assume that a good percentage of the visits are going to come from mobile, and a responsive template is pretty much standard nowadays for an informative site.
linuxmaniac: +1
sipidronov: +1
miconda: I am also sometimes on a tablet
abalashov: Mobile users are mostly not going to be power users, they're going to be casual / newbies looking around.
abalashov: So I don't think it's important to, say, make the documentation layout mobile-friendly.
miconda: looks like there is interest, we need to find some greenish theme
abalashov: But the core WP site and informative static pages, yes.
qxork: Exception… I do view mobile when looking at links from twitter, etc.
miconda: I have some experince with those from, all are green, a different one for each edition
abalashov: A lot of “business people” have the conceit that their life can be run from their iPad, and for better or worse, we have to cater to them I suppose.
abalashov: It would be good for the project marketing to do so.
qxork: anyone against it?
miconda: for documentation we have to see if we can generate from docbook xml on some responsive html css
miconda: I mean for module documentation
abalashov: miconda: The documentation renders fairly reasonably on mobile anyway. But I'm not concerned about documentation much; if someone is doing something serious, they're going to be doing it on a real PC. The static informative pages that are read by casual web browsers wandering in and out need to be mobile-friendly.
miconda: qxork: nobody — then will add this on a planed work for admin stuff
miconda: then find the team to work on it :-)
abalashov: Yeah… the problem is I don't really know much about WordPress. The few mobile-friendly (allegedly, supposedly) sites I've built were all handwritten with Bootstrap.
miconda: next topic then
abalashov: Otherwise I would happily volunteer to tackle it.
miconda: wordpress is not a big deal, it would be more about spending some time to select a theme
abalashov: (Huge props to @qxork for introducing me to Bootstrap; I'm kind of ignorant.)
miconda: I can even buy one, but my experience with proprietary themes are not good
afshin: I've used Wordpress with ElegantThemes theme, DIVI
miconda: the developer can dissapear as well :-) — wordpress has quite often updates
abalashov: Agree that they're not very flexible, nor is it necessary to buy one to maintain a basic “greenish” look.
afshin: it makes it Mobile First Design,
qxork: abalashov: next is getskeleton for very small loads
afshin: which means it will show fine on all devices
abalashov: qxork: I've since become familiar with Skeleton and SemanticUI, although stuck with Bootstrap.
abalashov: For what it's worth, my product site was WordPress with a proprietary theme.
abalashov: I found it insufficiently customisable and awkward.
abalashov: Tried probably 10.
abalashov: Ended up just rolling my own.
miconda: —— comunity interaction

Community Interaction

miconda: we have mailing lists and irc channel
miconda: anything else that we should consider
sipidronov: github
miconda: I am not sure if mailman 3 is out and stable, but it was supposed to bring sort of forum web interface
qxork: I wonder if we should do a monthly conference call.
linuxmaniac: I think mail + IRC + github is more that fine
qxork: q/a and then archive
sipidronov: linuxmaniac: agree
miconda: qxork: recorded?
miconda: qxork: I will join if I am available
linuxmaniac: google hangouts + youtube channel ??
miconda: but not sure I will be able to run it muself
qxork: miconda: yes. Like a quick status and then maybe ask the developer type questions
linuxmaniac: but for what??
qxork: tutorials, introductions, etc.
qxork: discussion of all that is kamailio
linuxmaniac: uff, who is going to do that?
miconda: if it is about development, I am even more interested :)
qxork: video is ok, but I have a face for radio.
oej: he he
oej: In this meeting I think we need to focus on what's needed for making life easier for developers
qxork: with audio, we could also make it a podcast
miconda: so, if someone can organize it, I will try to join as much as i can
oej: Such a conference call sounds like better for users - type “meet a developer”
abalashov: qxork: Sadly, my experience with such ambitious and idealistic ventures is that they tend to fade away unless they somehow manage to gain critical mass.
abalashov: It's probably better to shoot for something less ambitious but realistic.
qxork: abalashov: true
oej: We can start with scheduling monthly apperances with randy instead of starting something else.
oej: He already runs it and wants content all the time.
oej: I'm sure he'll agree to run a “kamailio corner” whenever we want to
abalashov: +1
qxork: oej: good idea
abalashov: He already has a pipeline to podcasts and distribution.
oej: Right
abalashov: We can benefit from that “transport layer”.
miconda: or we can try ad-hoc ones announced here if some dev has boring times
oej: I have been getting a lot of questions about videos - tutorials
miconda: announced on mailing list as well
oej: The new generation doesn't read README's
linuxmaniac: but who cares about new generation?
oej: But that's a quite large project
oej: linuxmaniac Yeah they can take their snapchat and go
linuxmaniac: people need to learn the hard way
oej: CLick their GUI's somewhere
linuxmaniac: RTFM
abalashov: Mailing lists are an interesting creature … most traditional, old-school UNIX guys like me prefer them, but certainly, they are a bit anachronistic and possibly even unfamiliar from the point of view of Millennials. But all the innovations in 'messaging' have been that – messaging. Slack, mobile messengers, etc. Not persistent forums for serious and lengthy exchanges involving a large number of occasional users.
abalashov: linuxmaniac: +1 :)
linuxmaniac: we are not a nodejs project
linuxmaniac: :-P
– abalashov require('kamailio.js')^H^H^H^H^H^H^H^H^H^H^H^H^H
linuxmaniac: next point please!!
oej: wget |/bin/sh
abalashov: I don't think Kamailio lends itself well to “video tutorials”.
abalashov: It's just not the sort of thing that it is.
marrold: I despise video tutorials.
qxork: I really never understood how to make a video tutorial of kamailio… “here's me typing.”
miconda: if anyone finds a useful tool, propose it at any time to sr-users
marrold: Maybe for an 'overview' or presentation of some kind. But not the nitty gritty stuff.
qxork: although, people would be impressed with abalashov typing.
miconda: I wanted to be sure that we don’t lack some very useful one
miconda: at this moment
abalashov: I don't think we've missed on any discussion forum innovation that can reasonably replace or supplant the mailing lists.
abalashov: All the innovation has been targeted at consumer sheeple who don't discuss anything because they lack personality and substance.
miconda: ok
abalashov: I give you Snapchat, etc.
trebuh: The main drawback I find to mailing lists is that it's not always easy to find useful info straight away
abalashov: No indeed, but any effort at a knowledge base or FAQ is bound to stagnate.
qxork: even with that, I still think the mailing lists are extremely in-depth and helpful
miconda: trebuh: suggestions to improve would be welcome
abalashov: Whereas the mailing list is “organic” … self-sustaining by default.
tuxd00d: Too many sheeple in the world…

Kamailio 5.0

miconda: — — kamailio 5.0
trebuh: miconda: I would shout them if I had found good ones, so for now, I just use it as it is.
miconda: oej is thinking of a meeting to hammer some of the bits for 5.0
oej: Yep. In STOCKHOLM!
miconda: I think won’t be bad at least for the part of restructuring the source code tree
linuxmaniac: miconda: thanks for working on lua stuff !!
– oej looks for php embedding
miconda: it will require some good perl/sed guys around :-)
miconda: linuxmaniac: welcome!
miconda: btw, app_python should be on pair with app_lua regarding the new embedded interface
qxork: I will help with the perl as much as possible, knowing I'm surrounded by better… but still love Perl
oej: I can host up to 10 people easily in the office
oej: With the largest shopping mall in Northern Europe just a short walk away!
tuxd00d: oej: php embedding?
miconda: I am fine with STOCKHOLM
oej: just a joke
oej: Or Stockholm
oej: :-)
linuxmaniac: Alicante is better!
oej: I would say only developers, no users or bystanders. People who has committed code
oej: If there's a free office available in Alicante I love the sunshine
miconda: oej: it summer is more sunshine up north :-)
oej: We just need at least three days locked into an office with free tea (and maybe coffee)
linuxmaniac: sure, we can talk with the university
sipidronov: Are you sure we still discuss 5.0? =)
drLester: I vote for Alicante :)
miconda: linuxmaniac: but we need internet access to get internet access
drLester: but maybe Camille could manage to have a place in Orange Gardens in Paris
oej: Stockholm is beautiful in the summer and more boring than Alicante, so more work will be done
miconda: and getting something during the summer in Alicante won’t be easy
abalashov: The real question in my mind is: what is the general aspiration with regard to this sudden and aggressive push to flesh out embedded language interpreter modules? Is it to expose more of the API into them, or to gradually push to replace the Kamailio route script DSL with something like Lua or Python entirely?
qxork: other than kamailio world, is there a conference coming where many devs will attend?
linuxmaniac: lua entirely
avb_: guys, how its possible to put dlg_manage() after carrierroute routing is done?
miconda: abalashov: one of the benefits will be reloading the routing logic without kamailio restart
oej: Back on topic: Dev meeting
linuxmaniac: and unit test of the config without kamailio loaded
oej: It seems like we need one
oej: We discussed this at Fosdem and I promised to check if I can get a free place
oej: Which I can
abalashov: Well, before we go down that road, it's worthwhile to remember why SER developed a DSL. Embeddable interpreters also existed in 2001. Presumably, the choice to hand-invent a DSL was made primarily for performance and expressiveness reasons. What has changed since then? I'm not saying nothing's changed – I'm sure a lot has changed to make this endeavour more realistic – but I think it's worth taking a pause to talk through that.
miconda: abalashov: and a more extensive language for ‘new cool and exotic’ needs
abalashov: I for one am not clear on why it suddenly makes sense now, 15 years later.
linuxmaniac: abalashov: no one forces you to switch to lua
miconda: abalashov: lua didn’t exist (or was not much known), python was slow, perl was not designed for parallel processing
linuxmaniac: you can still use the old kamailio config
sipidronov: suddenly agree with abalashov
linuxmaniac: we are not going to remove the kamailio DSL
abalashov: No, nobody forces anything, but practically speaking, as we know, things can take a general direction which causes some approaches to become less favoured, developed and maintained over time. So it's worth asking whether there is a high-level intention or aspiration to sunset the Kamailio DSL.
miconda: the current config stays there forever
miconda: the framework I work on is when writing a new function, make it easily available to kamailio.cfg routing blocks as well as to lua, etc..
sipidronov: But may be we could improve current mech to reload config etc?
miconda: so if I want to add “push_im_to_twitter()”
miconda: then I have to add it in two exports structures
miconda: one for classic kamailio.cfg routing blocks
miconda: and one for external embedded languages
abalashov: Fair enough. But one of the important things about the DSL is that it does evolve over time to have more characteristics of a general-purpose programming runtime. Since 3.0 it has evolved all these string transformations, convenience methods, some improved data structure primitives like XAVPs, etc. I guess my concern is that if there is a conceptual shift to, for example, a Lua orientation, such evolution will probably taper off. I'm not _necessarily_
miconda: in terms of technological aspects, it is quite simple and a lot of code is there
abalashov: against that, I'd just like that to be turned into a clear philosophical position, personally.
miconda: so for classic kamailio.cfg, there is an extra layer, called fixup at this moment
miconda: abalashov: I see your point, however in terms of new functions, it will be always in all the interpreters
abalashov: So, is it reasonable to say that, in an imagined future where the entire Kamailio config can be implemented in embedded Lua, the performance and throughput characteristics will remain the same? do_actions() may be ugly, but it's fast.
miconda: abalashov: not all config in lua, just the runtime active part, what are now routing blocks
abalashov: Many things about classic SER are ugly, but they were implemented that way for a reason – the project goal was high performance.
miconda: core parameters and modparams will stay like now
oej: For us classic config writers, the new APIs may make it possible to write new cool modules
abalashov: I'm not saying Lua poses a problem here, I just don't know what the implications of taking on this additional workload would be.
miconda: at least in foreseable future, I have no plans to change them
miconda: no benefits and it will add dependency on lua/… to the core
miconda: the workload is going to be rather minimal
abalashov: We have limited development resources. There is a zero-sum aspect to this. If you should get very enthusiastic about developing embeddable Lua and more and more examples and documentation and literature and blog posts and presentations and so on are forthcoming in Lua, it's not unreasonable to suggest that the traditional config writing might see a kind of decline in fashion, even if it will not, strictly, from a technical point of view, ever be remove
abalashov: d or obsoleted per se.
abalashov: So it's worth asking what this means.
miconda: many of the current functions execute some fixup to get from PVs the string value
miconda: then execute another function with those string values
– abalashov nods
miconda: an embedded interpreter will get the string values from the script and execute it directly, without going through the fixup stuff
miconda: I can give some quick example
sipidronov: having fixups didn't look that way bad for me
abalashov: I'm not really making a technical point here so much as an ideological one. There should be some coherent philosophical aspiration behind these changes; when we do more Lua, we are unavoidably making a methodological prescription to newbies and new users, even if we don't think we are.
abalashov: If that's the direction we'd like to move in, okay, but we should make some effort to decide that.
oej: On the current topic of the dev meeting…
abalashov: Otherwise it becomes very eclectic and confusing.
abalashov: Like, “you can write your config in Kamailio DSL… or also in Lua… or in Python… ¯\_(ツ)_/¯ we don't know”
miconda: abalashov: more and more choices :-)
abalashov: Well, you're a Mac user, right?
abalashov: There's an entire business empire built on the idea that more choice isn't necessarily good.
miconda: I don’t expect having a load balancer in lua/…
abalashov: So I think it's worth asking how this looks to the larger mass market, what the general idea here should be.
miconda: but I have seen some complex configs that will be simplified a lot by use of a well established language
sipidronov: but it would be nice to have LB able to reload configs though
abalashov: Certainly, and I write a lot of such configs. Very tedious control structures, awkward and ill-fitting uses of Kamailio's limited primitives, etc.
miconda: you know all kind of small libs that you can use for parsing or interaction with external systems
oej: We have had embedded language interpreters for a long time
oej: And they have been useful and Daniel is making them a lot more useful by exposing more of the Kamailio API
miconda: oej: exactly, the main aim is to make it easier to export to them
abalashov: Sure. These are all good arguments. I just want to know if there is a general movement toward Lua for config-writing over time. It's not a question of being forced to do anything.
miconda: so far required to write wrappers from scratch for each of them
oej: So I don't see this a a big change in directions, just a way to enable more functionality for lua, python, erlang and what else we ahve
miconda: my goal was write on export to all embedded interpreters
oej: No, I don't see a general movement
abalashov: I would expect that there should be some more generic mechanism for mass-export of functions and identifiers in the route script.
abalashov: Not tedious one-by-one export bindings.
miconda: abalashov: so far each of the app_module and app_python wrote their wrappers
miconda: so adding a function to app_lua didn’t mean it was visible to app_python
miconda: you had to code twice
– abalashov nods
abalashov: Has there been any evaluation of performance of embedded Lua vs. native DSL?
miconda: along with the C code in the module, which eventually exported it to kamailio.cfg as well
abalashov: I know it's fast, and I know we have modern hardware nowadays.
abalashov: But I assume performance was the main reason the SER project invented a DSL - an otherwise very tedious and labourious chore that is generally considered an antipattern.
miconda: abalashov: not yet by me
oej: I think the benefit has been to be able to reload during runtime. YOu can write code snippets and change without restarting the kamailio process
oej: It's not been speed, but flexibility
miconda: I know lua is very fast, so it may not be in pair, but not far from there
miconda: the cpu power is no longer like 2001
abalashov: Which is the general movement in interpreted high-level languages; lots of computing power, make it more convenient.
abalashov: And that's fine.
abalashov: Just wondering if it's a factor of 2 or something.
linuxmaniac: we have nothing to compare right now
miconda: probably in several days I can have kamailio-basic.cfg routing blocks in lua
abalashov: oej: Surely there have got to be other ways to skin the reloadable config cat in the current situation, though I acknowledge they may not be easy.
miconda: then some tests can be performed
abalashov: Anyway, I'm not arguing _against_ any perceived movement toward Lua, real or imagined. I just wanted to clarify whether there is one.
miconda: abalashov: that will require a lot of devel actually
linuxmaniac: miconda: but we have to come up with a generic solution for exporting the functions
miconda: current interpreter does a lot of optimizations in private memory
miconda: then you need to track how many workers and transactions are still using the current config to keep it in memory before destroying
abalashov: *nod*
abalashov: I'm sure there's some means of mass-mapping fixup layer → language bindings.
oej: OK, so we are all happy about the lua work.
oej: Dev meeting?
linuxmaniac: +1
sipidronov: Plz post some meeting minutes after the off-line dev meeting
abalashov: I can't imagine any concrete reason to be unhappy about it, but when a very small group of people are the major influencers in the larger community's perception of design patterns and authoritative, canonical methods and best practices for doing things in Kamailio, the question of what the new fashions will be is an unavoidably important one.
miconda: to conclude — kamailio.cfg interpreter is not going out anyhow, the other options are for those that need them and any extension to another embeeded language will require c code, which means making it available for kamailio.cfg straightforward
abalashov: One can do some basic things with Kamailio (given a bit of development experience) in a relatively short time. But going from 50% to 90% competence in a way that provides commercially viable expertise and can be deployed to solve any problem with Kamailio is a process that takes years.
miconda: I will try to make a tutorial about what means exporting to kamailio.cfg interpreter and the other emebdded interpreters
abalashov: So some sense of awareness of general trends is important.
abalashov: And in reality, we have a small oligopoly here of maybe a handful of people that are the source of larger mass-information about how to do Kamailio that most users of it rely on.
oej: I have spent hours and hours with APIs and json and http from inside of Kamaiio with many customers.
abalashov: There's nothing wrong with that, it's the way it is.
oej: that's a trend
abalashov: But it means trends are important.
oej: Absolutely
abalashov: So if there is a Lua-trend, intentional or not, this should be stated. That is all. That's the extent of my position. :)
oej: Daniel personally have been in love with Lua for quite some time now, as seen from the outside.
miconda: oej: :-)
oej: I am in love with htables. Keep misusing and using them for everything
miconda: actually i think Hugh and linuxmaniac added more extensions there than me
miconda: this time I did lot of stuff for app_python as well
abalashov: When there is a very small number of people accounting for the vast majority of work on the project, trends are important. It means that even when things will continue to exist strictly speaking, they will not have the same 'ecosystem tailwind' or 'spiritual support' or however you want to call it.
miconda: to show I am impartial :-)
abalashov: Just like the Perl module. Who actually uses that? :D But formally it exists…
abalashov: (I jest. I know people who use it, and I am rather sorry for them.)
miconda: at this moment it looked like a lot of devel oriented to so called kemi stuff
oej: After this discussion, can we get back on topic.
oej: I am still waiting for a conclusion on the real dev meeting
miconda: but that was because I had to write the core framework for it and inside the app_lua and python
miconda: from now on will be in the other modules, the usual C coding
abalashov: Aha.
abalashov: Cool, that's good to know. I didn't mean to derail the agenda.
miconda: oej: I am for it
qxork: abalashov: Back off the Perl mod.
qxork: ;)
miconda: anywhere in europe is fine
abalashov: qxork: :D
miconda: I would like visiting Sweden, been a while since last time
oej: SO when would be a good time? Europe can't agree on a holiday month
oej: We have IETF in Berlin this summer, so I'll go there twice in a short time
miconda: so, not in Berlin again :-)
oej: First half of June works fine for me
oej: or august
miconda: for 3rd time
abalashov: I think we can all agree that one of the items instrumental to the success of any project (or proprietary product) is to not offer _too_ many choices about how to do _fundamental_ things. If there are many options, there should be clear and distinct methodological rationales for why to use one or the other. It can be a serious hindrance to understanding if there are 5 ways to do a Kamailio config that are all kind of equal and simply a matter of taste,
abalashov: aesthetics…
oej: Abalashov: Please stick to the topic ;-)
miconda: probably I can do first part of June as well
abalashov: This is, after all, why people hate Perl. :-) (I say this as a Perl developer.)
abalashov: oej: All right, all right. :-)
miconda: for August I can commit to a date right now
oej: can or can't
miconda: sorry — I cannot
miconda: I need maybe 1-2 weeks
oej: ok, so that's two of us - what about the rest?
oej: How many do we think it will be?
miconda: at least two if in stockholm :-)
oej: We WILL have a great TIME!
drLester: for me for now it's ok june/august
linuxmaniac: June, the week of 6 to 12
linuxmaniac: is fine with me
oej: June 6 is our national holiday. The day of Sweden!
drLester: I mean july included :)
miconda: oej: so the queen/king can come and code with us, they don’t have to work :-)
oej: Either June 8-10 or June 20-22
miconda: maybe we should make a poll
linuxmaniac: 20-22 I'm at Alicante
oej: Those old grumpy people? YOu want the princes and princesses to come. Theyre a bit more cool
miconda: there used to be some online tools for this
miconda: doodle
oej: I can make a doodle
miconda: then send it to mailing list and see who and when can participate
linuxmaniac: please
miconda: and where
oej: Ok, that's a plan
miconda: then the next stuff
oej: We'll start with Stockholm (actually Solna which is closer to the airport)
miconda: an Ikea around for some meatballs at lunch?!?
oej: Not very close, but we can arrange group transport :-)
linuxmaniac: not paella?
linuxmaniac: :-P
oej: You have to bring a doggy-bag with paella
oej: And a lot of great wine!!!
miconda: —— next topic: source tree restructuring

Source Tree Restructuring

oej: yay!
miconda: I guess this needs to be decided when we meet and do it
miconda: not many variants, but still some
oej: agree, we need to discuss that a bit
abalashov: One of the things about the Kamailio source tree that makes me happy is that it has a fairly transparent and traditional build process.
miconda: most of the stuff is going to be find and replace afterwards
abalashov: I would not want to see this become 'opaque' and overly dependent on tools beyond 'make' as is currently very fashionable…
oej: I think we can agree that we want to move the core files away from root directory, but we can not currently agree on where to place them
miconda: yes, the root directory is too big
abalashov: I suppose the option is either to move it all into one core directory, or to separate core files thematically into subdirectories somehow.
miconda: abalashov: if no one is going to come with a new build system, at least I am not going to work on a new one
abalashov: miconda: I think the current one is fantastic. :-)
miconda: one of the questions is to add top src/ directory
miconda: like src/core
miconda: src/modules
abalashov: It's easy to work with for anyone who knows UNIX Folk Traditions. Most alternatives are for people who read Hacker News eagerly.
miconda: then have other dirs in root for pkg, utils, etc …
abalashov: I will say that the organisation of database schema definitions in places like utils/kamctl is confusing.
abalashov: And rather obscurantist.
oej: One big questionis whether to keep all platforms or to focus on Linux
oej: There's a lot of stuff that doesn't compile on OS/X now
miconda: oej: what happended to your *bsd side?!?
abalashov: oej: There is a small but significant and vocal contingent of people that like to run Kamailio on *BSD in my personal acquaintance, and they would be very upset with an exclusive Linux focus.
oej: We run Kamailio on FreeBSD in production on some large sites
miconda: oej: I do mainly development on osx these days
oej: And it's a bit annoying that modules doesn't even compile
miconda: what doesn’t compile there?
oej: I can understand that kernel-bindings like rtpkernelproxy stuff doesn't
miconda: I use macports to install various libs
oej: There's some timer issues
linuxmaniac: kamailio gets built for kfreebsd at Debian
miconda: timer issues?
oej: cdp and jsonrpc-c
miconda: linuxmaniac: were those commits I did making it work?
linuxmaniac: I didn't check yet
oej: jsonrpc-c has a dependency on timerfd - i don't understand why but haven't been digging either
qxork: it might be interesting to get a survey of deployment.
miconda: ohh, cdp — who runs ims on macosx
miconda: jsonrpc-c probably needs some update, I used jansson variant
oej: sctp also have issues on os/x if I remember correctly
miconda: jsonrpc depends on a lib that has also some more variants
miconda: does macosx kernel supports sctp?
oej: I am struggling to win my beer, so I need at least to be able to compile all modules on a single system
miconda: some of the features will be always os dependent
miconda: I guess
oej: yes, but an rpc module should not be
miconda: important is the core and main sip handling modules to be portable
oej: I can understand iprtpproxy or osxguiconnector and stuff like that
miconda: qxork: looks like you got something to do — get some stats about deployments ;-)
qxork: :)
miconda: iptrtpproxy needs to be moved to obsolete
miconda: it has a patch for an older kernel anyhow
oej: I don't think anyone has touched it for a very long time
miconda: now we have rtpengine that can do kernel forwarding
oej: And now we have the shiny rtpengine
oej: right
linuxmaniac: \o/
miconda: ok … this comes back to cleaning up the list of unmaintained modules
abalashov: I've never successfully built or used iptrtpproxy.
linuxmaniac: I'm planing to push rtpengine to Debian
abalashov: Though I tried several times over the years.
abalashov: Obviously interest evaporated when rtpengine appeared. :-)
oej: rtpengine on BSD!

DB schema backwards compatibility

miconda: — — next topic: DB schema backwards compatibility
miconda: abalashov and linuxmaniac on stage now … :-)
miconda: I haven’t had the time to respond on mailing list
miconda: but I don’t like either the current (old) way of checking the version table
linuxmaniac: so time to change it!!
miconda: I gues it was anyhow supposed to be a quick temporary solution back in 2001-2002 :-)
miconda: but what are 15 years compared with the life of universe :-)
linuxmaniac: so, no concerns about working on this?
miconda: linuxmaniac: no
linuxmaniac: please comment on the mail list
miconda: actually db api v2 has another mechanism
miconda: checking the required column names and types
miconda: maybe that part can be ported to db api v1 and then trans v2 as no many modules use it
miconda: to conclude — yes, it is something that should be worked on, let’s see on mailing list who can allocate resources and discuss there a design for it
linuxmaniac: I will work on this
linuxmaniac: for sure alutay want this
miconda: linuxmaniac: great!
linuxmaniac: so sipwise will sponsor my devel time
miconda: ——unit tests/continuous integration

Unit Tests/Continuous integration

linuxmaniac: but I would like to have a clear plan
abalashov: I am not a fan of the 'version' table concept altogether.
miconda: do we need unit tests or it is better to test it properly directly in production?!?
linuxmaniac: I have a plan to integrate autopkgtest to the debian process
linuxmaniac: my idea is to have at least a test to load every module packaged
miconda: linuxmaniac: that will be useful
linuxmaniac: at least we can check we have no problems with loading modules
linuxmaniac: unresolved symbols etc…
miconda: linuxmaniac: yes, it will catch missing symbols linking issues
miconda: at some point I was checking a python framework for unit testing
linuxmaniac: I didn't got time yet to implemented
oej: My idea with check_route_exists was to use include files and kind of autostart tests if they existed there.
miconda: it could generate reports that could be investigated via web
oej: so a generic kamailio config that includes test files and runs them in htable:mod-init
miconda: but if anyone is familiare with some toolkit for building unit tests, I am for
miconda: we have the lod servers provided by qxork that we can use for running unit tests
linuxmaniac: I would call that integration tests
miconda: actually I use one from time to time to run the ones from test/unit/
linuxmaniac: but I would provide a docker image for the environment
linuxmaniac: in order to be able to run that locally easily
linuxmaniac: first, I would say we should “force” modules to have a minimal test/unit/ for load it
linuxmaniac: nothing fancy
linuxmaniac: just provide a minimal kamailio.cfg with the minimal parameters
linuxmaniac: and check that kamailio starts
oej: or include files
oej: One for modparams and one for a test script
linuxmaniac: oej: we can think a way to have some templates
linuxmaniac: so we can provide a skeleton
oej: I know how hard it is to change a skeleton for over 100 modules
oej: better to have include files and one template kamailio.cfg
linuxmaniac: oej: noted
oej: tiny include files
oej: We're still removing svn id's, history all over the place and still have a few modules who need the core file renamed to match the module name
linuxmaniac: indeed
oej: (but we don't need to commit all changes to release branches… ;-) )
linuxmaniac: thanks for taking care of that
linuxmaniac: oej: you should use a nice prompt!!
miconda: as we are here, I jumped over one related item
miconda: tools for generating those indexes for modules docs
miconda: and other static pages …
miconda: perhaps we can create a new repo on github for them
miconda: more devs can commit there and then a cron.d to fetch locally on web server
oej: +1
miconda: one thing I am not happy about is the documentation for rpc commands
miconda: there is a tool to get the list of them from code
oej: We also still need devs to go over xml docs in their free time on the beach and add the section tags
oej: So we can have more data in the indexes
miconda: but the documentation about their parameters is missing
oej: So we need to go over that and add them to all xml files so the tool can create proper links
oej: the selects are the hairier one right?
linuxmaniac: yes, a new repo for the tools is fine
oej: They are very hidden but there's a script to find them
miconda: oej: at least with selects you know they return an int/str and most of them have suggestive name :-)
oej: That's something for the dev meeting to - the death or rebirth of selects for 5.0
miconda: but with rpc commands one needs to know the params
oej: Absolutely
miconda: i tried to add them as a section to my most used modules
miconda: however, some are in the core
oej: Right, that's a tough one
miconda: and, ohhh, there is also this reload framework for params
oej: We could have a core xml file in /doc for all that is hidden in the core
miconda: we should know which can be updated at runtime
oej: Hmm. I haven't personally looked much into how that's done in the source
miconda: e.g.,: kamcmd cfg.set_now_int core mem_dump_shm 1
oej: Is it a parameter when registering a modparam?
miconda: some of them are in the core
miconda: they were developed by the ser guys
miconda: it is not a bad concept at all
oej: No, it is good
miconda: we need to sort out the documentation for them
oej: Ok, a repo would be a good start
miconda: maybe there is a command to list them
abalashov: “one thing I am not happy about is the documentation for rpc commands” – +1
oej: Then we need to figure this out - what we need to do to be able to generate the dosc
oej: docs
miconda: yep
miconda: if anyone knows tools useful for building/maintaining docs, let us know
oej: If we can embed stuff in the source it's a good start. It's much easier to add a few things inline than going to a separate directory and writing stuff from the head
abalashov: Can someone enlighten me on the purpose of the xhttp_pi module?
oej: Asterisk has a way of writing AMI docs in the source code that has been working fairly well
miconda: at some point in the past Henning came with the idea to have some spec files for generating all thise exports structures
miconda: as well as the documentation from them
oej: then they added large XML chunks of stuff that was harder for a normal developer to handle
abalashov: Kamailio is rather low-level; most Kamailio endeavours involve some kind of programmatic integration or automation. Who is going to interactively browse RPC?
oej: No, but we can use inline docs to automatically generate text file and HTML files for the web site
miconda: abalashov: not using that module
miconda: osas did it, perhaps he wanted for small/embedded devices
oej: kamcmd may benefit from inline help
miconda: not to add another web server along
miconda: speaking of kamcmd — there is also kamcli which is supposed to combine kamctl and kamcmd somehow
miconda: but is python
miconda: it has of course access to lot of extension
oej: I have totally forgotten to test that. I am sorry.
miconda: one requested feature was “upgrade database” between versions
oej: WIll do
oej: I don't think any application should modify database structures automatically
oej: But that's me.
miconda: kamctl is shell/bash — quite limited to do complex tasks with it, but no dependency
miconda: oej: it will still be a human running the command
miconda: :-)
oej: Humans? Who trust HUMANS?
oej: A gui to click on
oej: Kamctl can produce a readable diff between what's in the DB and what's missing to help them.
miconda: kamcmd is just a binrpc client
miconda: wxtending it with other features will require c development, which I guess is not easy to find human resources for
miconda: extending it …
oej: kamcmd is so far away from a GUI we can be. User friendlyness is way after the last name of that application.
miconda: :-)
oej: Which is propably why I like it.
miconda: again, is just a bare bone rpc client for binrpc protocol
oej: Producing ten lines for one or two lines of needed information
miconda: kamcli is using jsonrpc
miconda: the binrpc protocol is some customized design by ser guys
miconda: and eventually at some point we will get rid of MI part
oej: We still have a few modules to convert from MI
miconda: and have only the RPC part for control
miconda: oej: indeed
miconda: and kamctl is quite used, we need to build the replacement of it to use rpc interface
miconda: instead of mi interface
oej: yes
miconda: ok, so two more topics

build system

miconda: — — build system
miconda: already touched somehow a bit
miconda: we have the old good Makefile system
miconda: I am happy with it
abalashov: +1
miconda: I plan to clean some conditions inside it for the older versions of gcc
qxork: i like it too
miconda: however, if anyone has suggestions for a better one and can provide a replacement, I am open to try it
sipidronov: I'd stay with existing one
oej: I think my primary issue is management of modules.lst
miconda: the only think I would like to work a bit on is to have something easier to select modules to compile
oej: I think some sort of GUI to enable/disable modules would be nice.
oej: right
oej: like a menuselect
miconda: oej: that’s what I wanted
miconda: maybe not necessary a gui
oej: a script that supports the process
oej: Or just an android app.
miconda: but somehow a format in afile to say this module should be compiled or not
oej: Regardless, the current modules.lst is complex
abalashov: like 'make menuconfig' in the kernel or its Asterisk equivalent ('make menuselect'?)
oej: right
abalashov: It would certainly be cool in terms of democratising the process of easily trimming down Kamailio to only the modules one actually needs.
abalashov: This is a common need with Freeswitch and Asterisk.
oej: Exactly
abalashov: I would be happy to contribute a tool for this, I am experienced with writing 'dialog' UIs in ncurses.
abalashov: But dialog would be a required dependency.
miconda: abalashov: we want to see it during dangerous demos at kamailio world :-)
abalashov: It is probably quite far from 'dangerous', at least I hope…
oej: We would need to change the file format first, then write GUIs
miconda: competing with oej’s longest list of loaded modules :-)
abalashov: My response to James Body when he asks me to do a dangerous demo is, “I don't really do 'dangerous' things, James…“
miconda: maybe we need sort of spec file per module
qxork: maybe the freeswitch style would be easier at first
miconda: to put there info like: compile by default
swimmercol: abalashov: I can give you a hand if you need it !
miconda: dependencies
abalashov: Well, my first stab at it would be to just dynamically generate the list of modules from the directory listings… but maybe that's not the right approach? Is there some metadata already that I should look at?
miconda: qxork: what is the freeswitch style? that file with the list of modules, some commented?
abalashov: I would accompany it with a reading of defaults from modules.lst to determine what is already checked.
abalashov: miconda: Yep.
qxork: yes, but one per line
oej: It should be in the module directory
miconda: abalashov: no metadata right now
oej: maybe even output by the makefile
miconda: there is some section in the readme related to dependencies
oej: make spec » /tmp/moddir
oej: But that section is not parseable
miconda: oej: requires humans for that, not bots :-)
oej: there is some metadata, like name of module, dependencies, uri to web sites for dependencies, common linux disto package names for dependencies
miconda: seriously, we should add some metadata
oej: in addition we have inter-module dependencies we could make parseable
miconda: that can be imported eventually inside the docbook, if it is going to be also xml
oej: If you add “dogwalk” then you need the “dog” module first
miconda: but have it as standalone file to be easy to handle by other tools
oej: Yes, the make system can make a docbook include file for the README based on this
oej: But I still think it belongs in the module directory to be managed in the same place as the rest of the module stuff
miconda: yes
oej: In that file we could have module state - current, not supported, deprecated, hated-by-everyone-but-still-here
miconda: :-)
miconda: ——last topic: roadmap to 5.0

Roadmap to 5.0

miconda: I guess it is too early
miconda: but if anyone wants to set some expectations, we can do it
miconda: from my point of view is going to be likely towards the end of the year
miconda: anyhow, we just released 4.4
miconda: probably we can come up with a timeline after the summer
miconda: based also on the results of the eventual devel meeting
oej: RIght. I would say in time for Kamailio world next year, so Q1 2017
oej: The question is if we need a 4.5 in between or just stay with 4.4
miconda: linuxmaniac: is any debian stable release schedule soon?
oej: I did add some new stuff to http_client - the connection reuse that is needed
miconda: I don’t think will be something to do for 4.5
oej: So maybe I should make you look somewhere else and commit that part to 4.4.1
miconda: the stuff with exporting to embedded interfaces is pretty much done
miconda: and already committed to master
miconda: anyhow, it doesn’t change anything big for the classic kamailio.cfg
drLester: the http_async_client also will have some major changes
miconda: then the big change will be actually the code tree restructuring
qxork: have to run – thank you all
drLester: and possibly I would like it to be merged with the http_client ;odule
oej: For 5.0 I want to merge the http_clients
oej: right
drLester: or using a common library
miconda: in a new module: http_merged_clients
drLester: before moving to the “big changes” for 5.0
drLester: :D
oej: More important for me is to remove curl from other modules using it
oej: By improving our API
drLester: +1
miconda: that would be good to do, indeed
oej: Hugh started on that so we're getting there at some point
drLester: so maybe this would justify a 4.5
abalashov: Kamailio ME (Millenium Edition)?
oej: Let's keep an open mind on 4.5 and see what happens in trunk
miconda: master can be used also in production
miconda: :-)
drLester: I think we more or less all do it :)
oej: I just love doing patching of running binaries
drLester: in a way or another :)
drLester: but we we're not regular users
miconda: 5.0 won’t be a big change for those using kamailio.cfg as it is now
abalashov: And can we please put some kind of easter eggs in the code? We are denying the user base the joy of discovering them, as well as the agony of searching.
miconda: there is no big refactoring of that
oej: I thought we where going to do all configs in JSON for 5.0 ?
– oej ducks
miconda: via http_client calling back on xhttp module
drLester: and what about embedded go?
oej: exactly
oej: one module to rule them all
miconda: drLester: that’s for you to add
abalashov: From 5.0, the Kamailio config will be declarative, strictly key=value.
oej: then a point-and-click lua-powered web site in xhttp-pi-++
abalashov: in keeping with its evolution as systemd-rtc-server
miconda: I stop at lua and python for external srcripting languages
oej: Oh yes, and tabs and white space will be significant
linuxmaniac: miconda:
oej: Ok, gotta go. It's been a good meeting.
drLester: smalltalk
linuxmaniac: 2017-01-05: “Softfreeze”
oej: Thanks for waiting for me
linuxmaniac: if you want kamailio 5.0 in debian has to be releases december
linuxmaniac: miconda: ^
miconda: linuxmaniac: ok
linuxmaniac: released
miconda: we should be able to do that, i think
oej: Sounds like a plan
oej: Kamailio Xmas!
miconda: Kamailio X/2 edition
miconda: ——anything else to discuss

Anything else?

miconda: I will try to make a summary and then see who volunteered for some of the tasks
abalashov: Put me down for the module selection menu idea.
miconda: for the rest I will randomly pick others :-)
abalashov: :D
miconda: abalashov: noted
miconda: looks like a 3 hours session today here — probably one of the longest one so far
miconda: glad we could sort some of the things and plan many others
drLester: thanks for leading Daniel :)
abalashov: This was my first IRC devel meeting, though I've meant to attend others in times past.
abalashov: It was quite fruitful and I learned a lot.
oej1: I have been looking into a generic AMQP module, I think we ened one
oej1: But on the other hand - is it even possible to make a generic bus interface and then “drivers” for different systems?
oej1: It seems like “send this blob” on “channel”
miconda_: … hmm, I was disconnected by the server … I did too much traffic
abalashov: Can't say, but I am opposed to the monopoly that Kazoo has on the entire concept, for its own ends. I don't know why we have to babysit a module that doesn't accomplish generic AMQP interaction that is generically useful to everyone.
miconda_: if there was some message after my “but on some design decisions, a quick chat may be more productive”, please repost
oej1: Lazedo has agreed that we need to strip the amqp out of kazoo, he's not opposed
miconda_: yes, it was a plan when the module was introduced, but nobody took over the task
abalashov: Generally speaking, I cannot just take a module that does some specific and narrow thing in CSRP and push it to the Kamailio repository and rely on you all to take care of it for me.
miconda_: eschmidbauer-mbp: seems to have some experience using it as standalone rabbitmq connectore
abalashov: It would be expected to have general utility and be stripped of proprietary nomenclature.
miconda_: if there is something open source in the other side, then we accepted always
miconda_: see the seas module
eschmidbauer-mbp: yes. it does not require kazoo platform at all
miconda_: which connects to wesip java application server
eschmidbauer-mbp: only thing kazoo about it is, the name everywhere
oej1: I don't think kazoo expect anyone else to maintain their module, like the OSP module
oej1: For me the agreement has always been “as long as you maintain it, we're happy to have it in the same code base”
miconda_: or seas :-), which apparently triggered some security alerts for some small issue
oej1: We could with the new system mark it as “3rd party maintenance”
abalashov: Personally I do not agree with this philosophy, but this isn't the Alex show.
abalashov: The OSP module doesn't belong either, IMHO.
abalashov: (especially since, as I've heard, there are some patents around OSP implementation – but I'm not sure of the details)
oej: I wasn't to happy with kazoo, as there was pieces in there that could benefit a wider audience in more generic modules
oej: Have not heard of patens of OSP, if so we may need to reconsider
abalashov: The thing is, if we're going to overhaul build systems and add lots of unit tests and CI and so on, anything we carry in the codebase has to be part of that, in theory.
miconda_: kazoo can still be split/renamed — it just needs someone between chair and keyboard to do it
abalashov: oej: I don't mean the OSP module or OSP itself is patented; no, it's an RFC, and it's the *Open* Settlement Protocol, after all.
oej: Right - and the current maintainer doesn't get upset
abalashov: oej: But it supports a particular business model, and isn't generically useful.
miconda_: what oej proposed with 3rd party maintenance could be useful
oej: Isn't it just an informational RFC
oej: I would be surpriced if that RFC was standards track
abalashov: That I don't know.
oej: Anyway thanks for today, I gotta go grocery shopping :-)
abalashov: Anyway, ultimately we have to take care of modules in more ways than just having a directory. Users expect support for them when they blunder into using them, test and CI coverage… etc.
abalashov: If we take on a module, the social contract should, in my opinion, be that it be generically useful.
abalashov: Otherwise it's basically a negative externality.
oej: In the future, I would like to be more restrictive with module names that reflect a company or another project
oej: But let's code and split the kazoo module apart! I need more modules to win the contest!
oej: :-)
abalashov: I'm not a dogmatic FOSS purist or anything. I grasp the concept that modules occupy a continuum.
abalashov: And that some are more generally useful than others.
abalashov: But I'm not excited about the idea of taking ownership of what are essentially strictly third-party components of other projects.
miconda: I never considered taking ownership of any module other that those I use
miconda: main point was that it compiles and someone maintains/uses it
abalashov: I think maybe there's some differences about the definition of “ownership”. To me, putting anything in the repository implies a certain amount of ownership by the project.
miconda: I test whatever I use
abalashov: That's why there's postgresql and there's postgresql-contrib.
tuxd00d: Having unmaintained modules, not designated as third party, does risk tainting the appearance of a well maintained Kamailio.
miconda: could be, but then it is also a matter of management resources for all this admin bits
abalashov: Or maybe they are maintained, but they just don't have much use except to the maintainer.
abalashov: I'm not a big fan of that either.
abalashov: And obviously, I mean use _in principle_.
abalashov: If a module has 1 user that's fine.
qxork: maybe “officially supported” desegnation
miconda: probably there are more kazoo deployments (kamailio+kazoo module), than other combinations
miconda: like kamailio+carrierroute as a stupind (and maybe not true) example
abalashov: As it stands now, shows a level playing field, where all modules look official and serious.
abalashov: That implies to most users that “whoever the lead Kamailio people are” support it.
tuxd00d: The problem with “officially supported” is the other modules don't get as much maintenance or use. Human nature.
qxork: unless someone offers to take ownership
qxork: developers leave, retire, move on…
qxork: if noone wants to take it, it's like a hobbiest module
miconda: on the other hand, adding officially maintained means pressure on devs
miconda: there are many lcr modules, developed/used by various companies
miconda: well maintained, eventually
miconda: but I don’t like to get hit for a bug in carrierroute
tuxd00d: Perhaps a page could be created that shows the status of each module in relation to the core? In a matrix table.
qxork: I think well maintained should mean that the dev of that module (or the company) be responsive to the bugs.
miconda: I do a lot of fixes to the modules I don’t use when a report is clear what’s the problem from C code point of view
miconda: but in terms of functionality, I try to avoid getting involved if I don’t use it, because I don’t have a fair overview of what’s inside
miconda: the first step would be to clean up some of the old, unsed modules (like iptrtpproxy)
miconda: then discuss what can be done for the rest
– linuxmaniac needs to leave
miconda: I will have to go soon as well
miconda: any other topics/concerns to sort out last minute here?
miconda: it the font of the source code nice enough?!? ;-)
qxork: just trying to make it so that officially supported <> miconda has to do it
miconda: qxork: to nail it down properly :-)
miconda: well, I do a lot that I don’t use
abalashov: miconda: Understatement of the century.
miconda: as a matter of fact, never used app_python and I don’t see myself of a python guy
miconda: could be good for scripts/cli, but is hard for me to go much into it given the whitespace-based blocks systems
miconda: and I still like the most kamailio.cfg with its native interpreter
abalashov: qxork is absolutely right that the project philosophy should not have the de facto, practical outcome that your workload and scope of responsibility simply grows and grows.
abalashov: FOSS lends itself to tragedies of the commons.
qxork: be nice if you could be holding the strings rather than having to do everything.
qxork: it means that to have your module be an “officially supported” module, you have a certain level of expectations
miconda: I also don’t like putting too many restrictions out there, that’s why I focus on keeping everything major in modules
abalashov: It goes without saying - but perhaps needs saying - that we deeply appreciate your hard work, @miconda, and that your diligence and attention to detail makes you the best manager of a FOSS project that I have ever seen in a lifetime of working with FOSS.
miconda: if someone doesn’t like it, don’t load/use it
qxork: +100 (weight based)
abalashov: But your hard work is a social good, and we should meet you in the middle by devising policies that do not leave you with the bill after everyone else leaves the restaurant.
miconda: abalashov: anything coming up as an issue to be solved quickly?!? ;-)
abalashov: :-))
abalashov: I am rather conservative on modules, maybe it means I don't understand the spirit of FOSS properly.
abalashov: But in my opinion if something passes into the project maintenance, it should be maintained by the project, but there must be a really good value case for doing so.
abalashov: Otherwise it can be downloaded from
miconda: :-)
qxork: I do like that approach
abalashov: And yes, it probably leads to a “second-tier” maintenance situations for such modules.
miconda: sometime is hard to predict the outcome
abalashov: But so what? You can't maintain everything.
miconda: I don’t use kazoo module (give it was used in many examples) at all, but as its developer came on board, Luis contributed a lot of code to presence and db_text modules
miconda: besides the fact that its name was supposed to be changed over the time
miconda: it is why I also tend to help new comers more/faster, because many of them turned into good community members, answering later to others
miconda: trying to impose like a limit on the first attemt to join even with a bad module, might be a loss of a good resource
miconda: in the first years of ser were a lot of constraints on who can commit where
miconda: there were long delays on accepting patches
abalashov: I agree that it is better to take the long view and not be very shortsighted about these things. But also in a mature project it's important to have some standards and find a balance there. Asterisk seems to have done a decent job of pivoting in that direction. Their patch submission process can seem a bit hostile to first-time contributors, as it's very meticulous, but I think they've got the right idea; if you want to contribute, you do have to play
abalashov: by our rules.
miconda: of course is not good to canibalize/balkanize everything, that’s again a focus on using modules
abalashov: I myself am pretty bad about submitting code without regard to existing conventions.
miconda: but with cvs/svn/git is easier to revert if something broken was made, rather than let the impressions of a ‘jailed’ environment
miconda: and people seems to have gotten to “gentlement agreement” rules of submitting patches/making pull requests even if they have commit access
miconda: if some part of the code they don’t maintain is touched
miconda: (I may not do it, though :-) )
miconda: unlike asterisk, here nobody does money selling licenses of the software
miconda: they have a more strict envirnoment for ages, requiring to sign some contributor agreement, etc …
– abalashov nods
miconda: anyhow, we can continue the discussions on mailing lists
miconda: lot of other people involved are not here now
abalashov: Okay! Thank you for hosting this, it was enlightening.
miconda: like developers
miconda: I will have to go now
tuxd00d: Thanks miconda
miconda: 8pm here and dinner is waiting
drLester: thanks
miconda: thank you all, as well!
miconda: if someone wants to go ahead and make a summary, you are welcome!
miconda: send to mailing list
miconda: I will try to select also the main conclusions
miconda: have a nice day/evening!

devel/irc-meetings/2016a-minutes.txt · Last modified: 2016/04/21 20:42 by qxork