Re: [PATCH] [RFC] Replace own http client with libcurl
Hi Paul, same with this one. Please always attach rather then inline. Thanks. Stipe mailto:[EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:[EMAIL PROTECTED] http://www.wapme-systems.de/ --- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.2 (Cygwin) mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2 nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H g2HyLAEKQIp30Q== =aYCI -END PGP PUBLIC KEY BLOCK-
Re: [PATCH] [RFC] Replace own http client with libcurl
Replying to Stipe Tolj: > Hi Paul, > > same with this one. Please always attach rather then inline. Thanks. Ok. Next time I'll follow the rules. Sorry for inconvenience, I just thought linux-kernel way where only inlined patches getting reviewed :) As for curl support - I posted it here just for testing. I do not intend to do such replacement right now. The code quality is not perfect^W^Wvery poor and I am asking, and even begging for peer review. The biggest question is: do you, as one of project leaders, recognize and will you support move to rip off the gwlib it's own http / https client code and instead put a dependency on well-known libcurl, thus offloading most of http / https / whatever compliance to 3rd party library, and allowing to concentrate on wap protocols instead? As for me, it is obvious. But I also think you have your own opinions on that :) -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head
Re: [PATCH] [RFC] Replace own http client with libcurl
Paul P Komkoff Jr wrote: > The biggest question is: do you, as one of project leaders, recognize > and will you support move to rip off the gwlib it's own http / https > client code and instead put a dependency on well-known libcurl, thus > offloading most of http / https / whatever compliance to 3rd party > library, and allowing to concentrate on wap protocols instead? > > As for me, it is obvious. But I also think you have your own opinions > on that :) now, that opionion of "me" is not that clean to be honest. I do gentely recognize that other projects do have considerable ammount of quality in their aims, like curl of course. Which is a pro factor in adding it to Kannel. On the other side, actually having to much dependencies makes things harder. Not even on the software, logic compliance related side, also on the licensing side. (we saw this right away the past weeks with the new mysql license and the implications for Kannel). Now, we have HTTP client code in there. Alex would say now: Ohh yes, we have, and I wonder how it works ;). Now, it does work, and we actually are not in demanding need to drop curl in there. But yes, it is an opion and having options is always good ;) I'll try to review and test the patch... comments comming... stay tuned. BTW, seems that you are eager in pushing development here. How about getting your hands to really open items, like the WTLS stack ;) -- which actually would need a SSL/TLS/crypto geek to do. Stipe mailto:[EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:[EMAIL PROTECTED] http://www.wapme-systems.de/ --- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.2 (Cygwin) mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2 nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H g2HyLAEKQIp30Q== =aYCI -END PGP PUBLIC KEY BLOCK-
Re: [PATCH] [RFC] Replace own http client with libcurl
Replying to Stipe Tolj: > now, that opionion of "me" is not that clean to be honest. I do > gentely recognize that other projects do have considerable ammount of > quality in their aims, like curl of course. Which is a pro factor in > adding it to Kannel. > > On the other side, actually having to much dependencies makes things > harder. Not even on the software, logic compliance related side, also > on the licensing side. (we saw this right away the past weeks with the > new mysql license and the implications for Kannel). Yeah, that's what I also had in mind. But remember: I _hate_ legal stuff :))) > Now, we have HTTP client code in there. Alex would say now: Ohh yes, > we have, and I wonder how it works ;). Now, it does work, and we > actually are not in demanding need to drop curl in there. But yes, it > is an opion and having options is always good ;) > Ok, I will rework it as a compile option or maybe a config file option. > I'll try to review and test the patch... comments comming... stay > tuned. The main reason for which I taken this piece of code is some badness in https implementation, according to my mood and schedule I decided it will be more efficient to do a quick hack and put curl in. So, for example, it will ignore http proxy options in .conf but will anticipate http_proxy environment variable :))) Also I am not sure how it will perform under very high loads. I tried to simulate it with fakewap but had no success, now I will try to simulate it on production site. Btw, one of my colleagues from St.Petersburg hit by memory leak in bearerbox (I will try to catch it tomorrow or the day after). > BTW, seems that you are eager in pushing development here. How about > getting your hands to really open items, like the WTLS stack ;) -- > which actually would need a SSL/TLS/crypto geek to do. Yeah, if I stay with this project for some time I will of course work on wtls. As you already understood :) I work in cellular provider for now, so I'm interested in all features working properly. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head
Re: [PATCH] [RFC] Replace own http client with libcurl
Paul P Komkoff Jr wrote: > Btw, one of my colleagues from St.Petersburg hit by memory leak in > bearerbox (I will try to catch it tomorrow or the day after). please file it directly to http://bugs.kannel.org/ to keep track of it. > Yeah, if I stay with this project for some time I will of course work > on wtls. As you already understood :) I work in cellular provider for > now, so I'm interested in all features working properly. that's good ;) Stipe mailto:[EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:[EMAIL PROTECTED] http://www.wapme-systems.de/ --- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.2 (Cygwin) mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2 nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H g2HyLAEKQIp30Q== =aYCI -END PGP PUBLIC KEY BLOCK-
