====== Greetings ====== [15:00:06] <__Henning__> ok! [15:00:16] <__Henning__> Now is the time. :-) [15:00:31] ok, hello everybody! [15:00:38] hello [15:00:38] <__Henning__> I hope anybody have joined us again. [15:00:57] <__Henning__> I think we try for now unmoderated, [15:01:16] I guess, Henning will lead the conversation, based on wiki agenda ... [15:01:21] <__Henning__> so please speak only up, if you have something meaningful to say [15:01:32] <__Henning__> thanks daniel! :-) ====== Experiences with OpenSER 1.2 ====== [15:01:43] <__Henning__> Ok, the first topic: Experiences with openser 1.2 [15:02:10] <__Henning__> I heard about some problems on the list and on irc, is anybody using this in production right now? [15:02:23] well, yes, we have it [15:02:30] :) [15:02:33] <__Henning__> any problems, e.g. with zombies? [15:02:39] we too [15:02:45] voipuser.org has int in production before full release [15:02:52] <__Henning__> how many users do you have? roughly? [15:03:00] we only have 500 users [15:03:06] but the half of them are call center agents [15:03:30] <__Henning__> and they call a lot, i think [15:03:52] yes, they do [15:04:14] but we use solaris, never saw a zombie there ;) [15:04:26] all issue we discovered are fixed ... no other issues [15:04:39] pending [15:04:44] <__Henning__> whats the state of presence? I see a lot of these issues [15:05:00] we don't have it in production :) [15:05:19] <__Henning__> yeah, cesc is probably the only who is using this.. [15:05:38] is indeed still a moving target ... but mainly in terms of internal design [15:06:01] we have it in testing environment ... [15:06:29] <__Henning__> ok. We're planing to move to 1.2 in summer [15:06:47] there are lot others using presence, or at list testing it [15:07:00] just resuming to mailing list traffic [15:07:03] <__Henning__> ok, i missed this, sorry [15:07:22] cesc's issues were related to presence + dbtext [15:07:45] dbtext should be integrated with openserctl [15:07:58] this combination revealed minor issues on both sides [15:08:23] <__Henning__> yeah, i read about it. osas: can you speak up? [15:08:50] <__Henning__> what kind of integration do you mean? [15:08:56] well, most of the time dbtext is not kept in sink with the other dbengines [15:09:18] the script for updating the tables [15:09:26] yes, thst is true [15:09:31] <__Henning__> yes. There was some discussion about the generation of this script from some metaformat [15:09:35] mainly because it is not so used [15:09:50] true, but it is part of the product [15:09:56] right :) [15:10:12] and for small embedded systems (routers, arm platforms) is is very useful [15:10:26] but when nobody uses it ... effort is too high [15:10:33] just setting the env ... [15:10:40] <__Henning__> yes [15:10:46] probably, all issues were fixed, if reported [15:11:04] probably distributing the effort among several people will solve the problem [15:11:28] <__Henning__> osas, how many resources do you have to work on this problem? [15:11:34] if the script would be merged, then the developer that is updating the mysql tables would see that it needs to update the other tables 2 (postgres/dbtext) [15:11:46] 1 (me) :) [15:11:47] Hi! Soory to interrupt you. I just wanted to say that I have to leave soon, thus putting the irc session log on the homepage would be nice [15:12:02] <__Henning__> klaus: allready planned [15:12:13] IMO a developer should know that there are 3 db-scripts to update [15:12:34] yes ... should ... [15:12:39] :) [15:12:58] <__Henning__> perhaps we can write a some file with the tables, and use a perl script to generate the tables for the 3 other scripts from them? [15:12:58] after cesc's update, all are being updated [15:12:59] the mysql and postgres are somehow integrated and dbtext is left aside ... [15:13:02] as of my knowledge [15:13:02] right - but from my experience, knowing C and mysql and postgres and dbtext is not realistic ;) [15:13:08] big troubles were in the past [15:13:38] I mean having the knowledge to deal with all of these parts [15:14:27] ideally, each person should perform tasks he is good at - this will minimize the effort and time required to complete the taks [15:14:35] on the other hand, sc.dbtext is not installed, maybe that's why is not that used [15:14:59] <__Henning__> ok, perhaps we should install this. [15:15:25] to add to the possible confusion, is sqlite something that is worth spending effort on ? this would mean yet another engine to be kept in sync . [15:15:48] <__Henning__> NormB: perhaps we can talk later about this? [15:15:49] we have unixodbc ... [15:15:56] <__Henning__> as part of the roadmap discussion.. [15:16:26] <__Henning__> and we could move to the next topic, if nobody object ====== OpenSER hosting ====== [15:16:37] <__Henning__> -> OpenSER hosting: [15:17:08] __Henning__: I know I'm new to openser, but I'm willing to offer any hosting or build system that's need [15:17:10] needed* [15:17:12] <__Henning__> At the moment the server is hosted at voice systems? Daniel? [15:17:23] is hosted in Germany [15:17:31] yes it is hosted by VS [15:17:32] with the possibility to setup a build bot for regression testing and or packaging for a couple archs [15:17:37] <__Henning__> codestr0m: thanks [15:17:38] let's say, just sponsored by VS [15:18:01] <__Henning__> we can sponsor a dedicated server too [15:18:17] the issues is that the machine is used for both openser related taks and for our internal needs [15:18:37] <__Henning__> and you plan to move the openser stuff to an dedicated machine [15:18:46] and this mix generates a lot of problems - mainly, people from outside VS cannot have access to this machine [15:19:07] <__Henning__> ok, understand, a dedicated server would be nice [15:19:26] <__Henning__> what are your requirements, in kind of hardware? [15:19:31] <__Henning__> CPU, Mem, HD space [15:19:36] that will be the idea - to have a dedicated server for openser and grant access to people interested in contributing to its maintaince [15:19:44] I'm still willing to sponser a dedicated server here in NJ. We had one running back when sourceforge was having problems. Haven't done much with it as resources are tight. [15:20:25] we can also offer the server, bandwidth, etc... [15:20:28] there is also another offer for a dedicated server from Voztelecom - the guys contributing the weSIP AS [15:20:44] jesusr: talking about you [15:21:04] <__Henning__> ok, i see, we have enough possibilities :-) [15:21:59] so, we have like 4 options so for, right? jesusr, _Henning_, codestr0m, SormB [15:21:59] i have space, power and bandwidth at telehouse UK if its of use also.. [15:22:17] now 5 :) [15:22:33] I've got 20Mb at SJC with another pop going in at AMX-IX within 60 days [15:22:42] <__Henning__> ok, all this offers are dedicated servers with a root account and no virtual server stuff? [15:23:08] <__Henning__> i mean, we are the only users on the machine? [15:23:48] good question :) [15:23:53] __Henning__: is that really needed? what are the real needs and or differences that would be desired? [15:23:54] i can offer everything but the box at the moment.. [15:24:43] well. on the wiki I read that have binaries built would be interesting.. I'm already building packages for multip dist across 3 arch and can cross build more if needed [15:24:49] The box here would be dedicated. This could lead to an interesting distributed/load balanced environment [15:25:00] <__Henning__> here too [15:25:10] yes in our case... dedicated server with root access... [15:25:28] actully the servers will be needed for multiple purposes [15:25:36] <__Henning__> ok, to wrap this up: we have at least three different servers for us [15:25:39] I would offer that, but the box wouldn't be impressive then... on it's own vlans and throttled [15:25:41] like : web, ftp, svn [15:25:57] <__Henning__> mailman, wiki [15:26:16] Henning: right [15:26:42] <__Henning__> so who will do the administration of this services? security updates are important too [15:26:55] i can make a specific service or services available.. so if http, or ftp was needed.. maybe as part of a mirror.. [15:27:03] any volunteers ?:) [15:27:13] well. I was going to do it, but if I give root [15:27:21] Henning: we can split the tasks [15:27:28] I will just let it be someone else's responsibility [15:27:39] there is no need for a single person [15:27:47] Verlassen jesusr hat den Kanal verlassen. [15:27:49] <__Henning__> codestr0m: understand [15:28:00] <__Henning__> bogdan: yes [15:28:07] well. I already host and manage 20+ servers and can just as easily plugin one more site in [15:28:41] <__Henning__> codestrom: this should not be the problem [15:29:03] k. If anything is needed. I'll take the passive on this then.. doesn't effect me [15:29:26] <__Henning__> codestrom: no, i mean that the administration is the hard part.. [15:29:34] I think we need to go step by step - what services we need to run, what machine and how mwny to use, hoe will be in-charge and for what [15:29:59] <__Henning__> yes, we don't need run into all this detail now [15:30:28] <__Henning__> http, mail, wiki, svn, shell? [15:30:42] __Henning__: what would shell be used for? [15:30:42] let us build a list on wiki [15:30:57] <__Henning__> just ask, i don't need this [15:31:33] <__Henning__> ok, i'll start a new page on the wiki, development:hosting after the meeting. [15:31:59] Henning: super - lets first close the list of services we need [15:32:14] <__Henning__> anything else? you mentioned build service? [15:32:34] Henning: yes, there is an important and critical issue [15:33:02] unfortunately we do not have access on different OS or ARCH [15:33:07] <__Henning__> for what machines? x86, x86_64 and sun? [15:33:09] why not using virtualization for creating a build farm if the server is powerfull enough ? [15:33:18] I can crossbuild for all of them [15:33:20] bogdan_vs, well qemu is interesting in that case [15:33:22] and openser wants to be supported on as many as possible [15:33:27] <__Henning__> toady: that could be an option, thanks [15:33:44] (btw, I am SebastienTricaud) [15:34:01] in the last year there were a lot of complains about openser on Solaris [15:34:27] <__Henning__> i think the situation is now better, but a build host would be nice [15:34:28] bogdan_vs, thus, that would be nice to introduce a buildbot and have unit testing for each plateform [15:34:30] not to get too technical, but as long as gcc will compile it and I can chroot into it.. a package is possible [15:34:40] not necessary related to compilation, but for runtime experience, install tolls. etc [15:34:45] i can make a zone available on x86 solaris [15:35:06] sorry : tolls -> tools [15:35:20] <__Henning__> L-info: thank you for the offer [15:36:02] <__Henning__> ok, for this we need people with solaris experience [15:36:04] so far we had the compile farm from SF, but they closed it :( [15:36:13] __Henning__, I can help setting the virtualization up [15:36:33] <__Henning__> toady: good, noted [15:37:31] Henning: should we start a new list of what OS and ARCH people can offer access on for compile / install test purposes ? [15:37:41] maybe on WIKI too :) [15:37:54] <__Henning__> just think about it.. :-) [15:38:03] or maybe os and arch you guys want to test on [15:38:15] then people can approach as and when resource is avail [15:38:16] ? [15:38:27] L-info: as many and as vary as possible :) [15:38:32] :) [15:38:35] as time they are unix like [15:38:37] of course [15:38:51] <__Henning__> ok, you'll reach this page from the hosting wiki page i'll create [15:39:09] <__Henning__> what is with bugtrack? bugzilla? [15:39:42] <__Henning__> do we would go away from sf.org completly? [15:39:47] it is a bug tracker system [15:40:05] <__Henning__> bogdan: yes, do we need our own? [15:40:07] jira offers a very nice system to open source projects [15:40:18] Henning: no - I would say we should stay with SF for SVN and tracker [15:40:37] <__Henning__> ack, my opion too [15:40:46] SF provide a visible place for projects [15:41:06] no need to complicate our lives more than necessary :) [15:41:11] bogdan_vs, or switch to trac is an option maybe [15:41:19] :) [15:41:35] <__Henning__> yes. good, to wrap this up: two pages on the wiki for hosting and buildservice, and sf.org for svn and tracker ====== Documentation ====== [15:42:02] <__Henning__> next topic: OpenSER documentation [15:42:26] <__Henning__> we don't have any hacking/ starting guide for new developer at all [15:42:35] <__Henning__> at least no that i know about [15:43:02] the old admin tutorial from the SER site is pretty good [15:43:11] it is still hosted on the old iptel website [15:43:22] <__Henning__> yes, i read it too. perhaps we can update this? [15:43:23] maybe it should be updated for openser [15:43:27] svn co svn://openser.oralnet.co.uk/guide/trunk [15:43:33] universal read access [15:43:40] docbook approach to doing exactly that [15:43:44] but its taking a long time [15:43:58] <__Henning__> L-info: thanks! do you start this from the scratch? [15:44:02] yea [15:44:21] <__Henning__> how much work still needs to be done? [15:44:37] Nick Defraz_ nennt sich jetzt Defraz. [15:44:55] <__Henning__> L-info: or is this guide ready? [15:45:07] plenty.. i got a lot of writing done, and some of the scripts [15:45:39] but have only got the mysql db/nathelper/rtproxy stuff done.. i.e. the basics [15:45:44] <__Henning__> ok, perhaps you can add a link to the wiki? [15:45:57] havent approached avps, dispatcher and the other more pertinent topics that answer a lot of repeat questions [15:46:26] Henning: or generate the docs in html format - not sure what is on the SVN [15:46:40] i will get it html-ized daily and post a link to that.. then post the svn details on dev mailing list [15:46:47] if that is okay? [15:46:52] <__Henning__> L-info: thanks [15:47:07] L-info: yes, that will be great [15:47:08] <__Henning__> bogdan: i think what is need is some kind of high level overview about the code [15:48:09] <__Henning__> bodgan: do you have any spare resources at VS for documentation? I mean, you now all this history behind the code :-) [15:48:14] Henning: right - an overview of the openser's architecture [15:48:43] Henning: well.....difficult question...:D [15:48:52] <__Henning__> i know, nobody likes to documents.. [15:49:40] <__Henning__> for users it [15:49:53] Henning: for development purposes? [15:50:00] <__Henning__> yes [15:50:16] <__Henning__> like the old SER hacking guide [15:50:30] Henning: I do not make any time promises, but I will give it a try..... [15:50:36] For development I would like to have a document describing even shortly on how to add new presence event packages. [15:52:01] jih:later we can integrate detailed documentation for modules [15:52:29] Henning is right - we do not have the documentation of the "big picture" yet [15:53:06] <__Henning__> ok, from the high level more closer to the code.. [15:53:12] <__Henning__> we're using Doxygen now.. [15:53:18] jih: Anca will prepare some docs in the near future [15:53:44] just committed a better architectured presence module [15:54:13] as I understood, adding handling for new events should be easier [15:54:30] <__Henning__> daniel: thats good to hear [15:55:05] <__Henning__> do we plan to use more doxygen documentation for files and functions? [15:55:14] bogdan_vs: maybe an update of the old SER Programmer's Guide (you were listed as author :-) [15:55:59] that was our starting point in digging into the openser code ... [15:56:17] <__Henning__> or should we try to work first on this high level issues? [15:57:06] osas: to me honest I have no clue what's in that guide.....:) [15:57:15] lol [15:57:21] <__Henning__> :-) [15:57:33] http://old.iptel.org/ser/doc/serdev/serdev.html [15:58:55] <__Henning__> ok, as documentation is not such a priority.. Let's move to the next topic: ====== RTPProxy ====== [15:59:09] <__Henning__> -> RTPProxy [15:59:17] <__Henning__> Daniel: this is from you? [15:59:27] yes [15:59:42] there is at least a patch on our tracker [16:00:10] osas and danb (plus some I don't recall), expressed intention to add improvements [16:00:20] yup [16:00:32] mainly to accounting reporting, transconding, scalability [16:00:34] perhaps a rewrite ? [16:00:45] one was already done :-) thx to VS [16:00:52] I contacted Maxim in january, got so reply so far, I will do it again ... [16:01:20] but, as NormB says ... rewrite() or ??! [16:01:24] what to do? [16:01:54] so, the options: [16:01:57] well, first a re-contact and will see after that [16:02:00] I've been looking a a redesign for awhile, but need additional resources. [16:02:06] pushing forward with Maxim [16:03:11] if someone wants to take the lead, i'll sign on to help. [16:03:12] in the happy case, we will have good collaboration [16:03:45] second: redesign from scratch [16:03:59] <__Henning__> ok.. That should be much work [16:04:03] think threads [16:04:04] many resources to be allocated in the begin [16:05:00] NormB seems to be for second [16:05:06] osas for first [16:05:11] <__Henning__> first [16:05:13] any other? [16:05:49] <__Henning__> no.. [16:05:55] in first case, how long we should wait? [16:05:57] Iwould say first [16:06:22] <__Henning__> waiting for an e-mail reply? [16:06:28] yep [16:06:35] or collaboration agreement [16:06:36] rtpproxy is part of the SER repo ... is that right? [16:06:41] yep [16:06:54] it might be a matter of patch acceptance as well [16:06:58] how long will take [16:07:01] is there someone here who is part of the SER mailing list? [16:07:18] maibe we should post the question/patch on the SER mailing list [16:07:46] rtpproxy enhancements should benefit both projects [16:07:59] I'm on the ser mailing list [16:08:06] <__Henning__> i think the same [16:08:08] I could do it, but if I would say the patch is on openser tracker, I will get some "noisy" feedback ... [16:08:20] can you point the SER community about this patch? [16:08:20] I don't care what feedback I get [16:08:46] let's not worry about feedbacks for now [16:08:53] we want to move forward :-) [16:09:06] <__Henning__> ack. codestr0m: could you ask about this patch? [16:10:30] I can subscribe to SER mailing list and ask ... [16:10:54] I will do it [16:10:59] let's move forward [16:11:01] if we take option 2 (rewrite), i might be able to get some funding for this project.. [16:11:08] just as an aside [16:11:10] <__Henning__> osas: thank you [16:11:36] http://sourceforge.net/tracker/index.php?func=detail&aid=1575919&group_id=139143&atid=743022 [16:11:45] just to have the link to patch [16:12:14] <__Henning__> ok, we'll try this with the patch, and if the response is negative, we'll think again about option 2 [16:12:33] Henning: ok ====== Next Release ====== [16:12:43] should we move to "Next Release" ? [16:12:52] <__Henning__> -> next release [16:13:04] major or minor? [16:13:24] <__Henning__> there are allready some important fixes in 1.2, i go for minor [16:13:44] ok, both should be discussed, which first [16:13:48] ok, minor [16:13:52] first the minor [16:13:57] when? [16:14:11] <__Henning__> next month? [16:14:21] and how? (I mean, all packaging from scratch ...) [16:14:37] Henning: should be ok - we have time to hunt for more issues [16:15:03] actually what is important is the feedback from people using 1.2 version [16:15:11] <__Henning__> bogdan: yes [16:15:58] <__Henning__> packaging.. debian is no problem, for rpm we had the opensuse service [16:16:20] Jesus will handle the FreeBSD port [16:16:53] Jesus (jesusr) from Voztelecom [16:16:58] :) [16:17:53] <__Henning__> all the packaging stuff should work for the minor release, the change is not so big [16:17:57] Julien Blache did good job with openser in official debian ... [16:18:10] ok [16:18:32] <__Henning__> So, rough date: middle of may? [16:18:45] ok [16:19:21] <__Henning__> major release..: [16:20:39] <__Henning__> we don't have a roadmap now.. so planning is a little bit difficult [16:21:27] we can try to identify the areas of interest for the next major [16:21:44] and based on this, to make a time estimation [16:22:58] <__Henning__> ok. [16:23:10] <__Henning__> presence? [16:23:13] <__Henning__> and releated modules? [16:23:26] one item for the next major release might be tighter integration of xmpp into openser. [16:24:39] and dialog enhancements [16:24:47] some steps already done with xmpp [16:24:56] simple-xmpp presence in the trunk right now [16:25:28] osas: I have dialog on my list - there are already 2 patches pending on this topic [16:25:39] Yes, but it would be nice to get rid of two lavel addressing for xmpp. [16:26:34] indeed [16:26:50] is there any interest in better diameter support? [16:27:34] <__Henning__> we don't use this [16:27:52] How about SIPS URI scheme? I Ipersonally don't like the whole idea, but there is some demand. [16:27:55] it is more IMS oriented ... [16:29:20] Juha: are there any missing part for SIPS [16:29:21] ? [16:29:22] Regarding TLS in general, perhaps openssl lib should be replaced by gnutls. [16:29:40] <__Henning__> yes, to get rid of the licencing problem for debian [16:30:00] bogdan: There is some missing pieces in the parser at least. [16:30:42] Also, in some modules "sip:" is hard coded. [16:32:03] regarding TLS: gnutls seems to be more stable and bug-free, however there is a performance issue here: gnutls seems to be 2 times slower then openssl [16:32:21] I have heard that gnutls also supports offering multiple certs during ssl setup, which would allow getting rid of multiple listening ports. [16:32:57] <__Henning__> anybody know how different is the interface of gnutls to the from openssl? [16:33:09] TLS - Julien Blache announced to me the intention of patching for gnutls [16:33:15] I have to check the status [16:33:37] but for sure is something worth investigating [16:33:49] gnutls seems fore flexible and dynamic [16:33:56] it is :) [16:34:51] <__Henning__> i could work on application db clustering for really big installations [16:35:34] henning: is that something else than mysql based clustering? [16:36:02] I do postgres near real time replication with slony [16:36:13] <__Henning__> it is openser based, so you have e.g. 1/3 of the userloc data in three dbs [16:36:34] DB layer redesign should be on the topic of next irc meeting [16:36:43] we have some interesting ideas, hope to get more [16:36:57] mainly related to scalability an failover [16:37:19] now we may get the meeting too long for some ... [16:37:27] <__Henning__> i think the same.. [16:37:43] <__Henning__> we have 2 more issues left, p2psip and openser as library [16:38:13] p2p -- did minor investigation [16:38:29] rtpproxy patch posted to SER dev mailing list: http://lists.iptel.org/pipermail/serdev/2007-April/009885.html [16:38:29] isn't the idea of p2psip that there is nothing in the middle? [16:38:37] not sure if worth right now, unless big involvement from third parties [16:38:52] jih: something has to be [16:38:53] <__Henning__> i think the same [16:38:58] for auth ... [16:39:05] but routing is different [16:39:08] that something could be dns. [16:39:32] dns authentication and authorization? [16:40:20] i'm not familiar with the latest regarding p2psip, but i have heard about user certs for authentication. [16:41:09] there are proposals and proposals [16:41:22] the point is where money is going [16:41:33] certs is the best for CAs :-) [16:42:17] perhaps p2psip is still too much a moving target for openser. [16:42:41] <__Henning__> ack [16:42:47] <__Henning__> the openser lib question is from toady [16:42:50] unless someone do really invest on it resources ... [16:43:01] Hope it's not OT, but I'm using OpenSER with some C++ code. One problem I had was OpenSER's use of C++ keywords as identifiers (e.g. delete, class). Including the header made the C++ compiler break compilation. If you are thinking about libifying OpenSER, I think this should be taken into account (and maybe it could even be fixed short term, since it should not be a big deal)... [16:43:23] <__Henning__> frey: please wait some minutes, we're in a meeting :-) [16:44:09] <__Henning__> frey: but thank for the remark! [16:44:10] __Henning__, I am here :-) [16:44:51] the problem with extracting a stack from openser is that there is no clear separation line between parser and engine [16:45:22] bogdan_vs, actually, I did made a lib from the parser very easily [16:45:47] bogdan_vs, first of all, instead of technically worries, what do you think of the idea ? [16:46:11] probably only for parsing a sip requests ? [16:46:23] yes [16:46:34] and responses :-) [16:46:42] well... parsing sip :-) [16:46:50] <__Henning__> for this task there exist allready SIP libraries that are better suited to the task, i think [16:46:52] I guess parser/ directory is for that [16:46:57] toady: well...as I never had the need for it, I never did too much thinking on the topic [16:47:07] __Henning__, I am not that sure on this [16:47:30] bogdan_vs, I am working on a SIP intrusion detection system [16:47:43] <__Henning__> ok, you need high performance? :-) [16:47:51] bogdan_vs, using netfilter queue library [16:47:55] __Henning__, right :) [16:48:17] <__Henning__> ok, then is a java/ c++ lib probably not the right thing to use.. [16:48:19] __Henning__, and I did look at several sip parsers and I can tell the one is pretty good :) [16:48:33] __Henning__, especially when manipulating things on top of netfilter [16:48:50] and I think there is a room for such a parser [16:49:53] toady: did you do any changes in the code in order to extract the parser as a lib? [16:50:04] bogdan_vs, a little bit [16:50:16] bogdan_vs, most of changes where to move some headers etc.. [16:50:35] it really took me 3 hours to get the lib working [16:50:46] toady: can you post them? we could integrate and have a "make sip_parser" for who's interested [16:50:53] bogdan_vs, sure [16:51:06] <__Henning__> i would also like to look [16:51:17] bogdan_vs, I can even work on it. I am very interested. [16:51:24] * toady is putting stuff online [16:51:42] <__Henning__> toady: ok, simple join the devel list :-) [16:51:54] I am on the devel list :) [16:52:10] <__Henning__> ah, sorry. :-) [16:52:13] toady: submit a patch on tracker + devel [16:53:14] there is one more think I;m considering for 1.3 [16:53:36] www.wallinfire.net/files/libsipparser.tar.gz [16:53:49] bogdan_vs, ok, I'll do that then [16:54:04] toady: OK - thanks [16:54:09] bogdan_vs, ok then I have an other idea: [16:54:14] <__Henning__> bogdan: yes? [16:54:19] if we think of splitting stuff in libraries [16:54:25] we would have something like: [16:54:30] [ parser ] [ ...] [16:54:45] [ base ] [16:54:46] ok - let's finish the lib discussio [16:55:02] <__Henning__> ack. Do you have another thing for 1.3? [16:55:02] the base would handle stuff like memory allocation [16:55:11] -but- [16:55:19] there are already such libs [16:55:24] I am thinking of libapr from apache [16:55:29] maybe there are other [16:55:43] <__Henning__> toady: this was my first though after i saw pck_malloc :-) [16:55:56] maybe this is a bad idea since the base library is exactly what is needed by openser [16:56:02] __Henning__, :) [16:56:19] so, I'd like to know whether you would like it or not [16:56:27] practically, this mean: [16:56:45] toady: could you detail your idea in an email? [16:56:45] - I look of its feasibility (and provide a patch for the base library first) [16:56:49] bogdan_vs, ok [16:56:55] bogdan_vs, I will do that then :-) [16:57:09] <__Henning__> Ok. We're are allready much to late.. I thank you all for your participation! I'll add the minutes to the wiki, and keep you informed about the next meeting! [16:57:11] I thinl we are getting too technical for this discussion ;) [16:57:31] <__Henning__> bogdan: or do you have some last point for 1.3? [16:57:51] maybe next time we should set a target for the duration and try to stick with it [16:57:54] Henning: short one - about the ASM code from openser [16:58:27] <__Henning__> osas: i planned one hour, not exactly a perfect match.. :-/ [16:58:37] there were/are problems with it depending of the exact arch, compiler capabilities, etc [16:59:29] so, I was investigating the following idea: instead of having ASM code depending of ARCH, why not reusing asm code provided by OSs?? [17:00:01] doing this we do not have to maintain ASM code in openser, but rely on OS [17:00:20] linux, solaris and bsd offers asm functions for spinlock, atomic ops, etc [17:00:33] <__Henning__> ok, so then we should use them [17:00:50] but first we need to do some performance tests ! [17:01:05] to avoid any perf. degradation [17:01:13] <__Henning__> i know that would you say this ;-) [17:01:27] :) [17:01:49] I will take this task on me.... [17:01:57] so, I'm done ====== Bye ====== [17:02:01] ok then, hope was an interesting electronic meeting :) [17:02:16] e-meeting ;) [17:02:29] <__Henning__> next time we're doing this over RTP [17:02:33] <__Henning__> :-) [17:02:34] next time we should use SIP IM conference!! [17:02:36] quick note: there's a quick'n'dirty log of daily irc chat @ http://openser.oralnet.co.uk/irc/openser/