AW: Using kannel's WAP-stack
Jörg Pommnitz <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
As I wrote some time ago: in this case the protocol stack entities should be decoupled from the current model "one thread per entity". They should just receive and handle the WAPEvents. Whether they run in their own thread and get their input from queues or inside a state machine should not be hard coded in the WAP library. Regards Jörg -----Ursprüngliche Nachricht----- Von: Stipe Tolj [mailto:[email protected]] Gesendet: Donnerstag, 11. März 2004 13:40 An: Joachim Breitner Cc: [email protected] Betreff: Re: Using kannel's WAP-stack Joachim Breitner schrieb: > > Hi, > > > Take a look at fakewap.c in the Kannel src tree. It's a good place > > to start for a WAP client. It lacks certain features (SAR, WTLS) but > > its better than starting from scratch. > > fakewap.c seems to use hardcoded WSP and and WTP packets. I was rather > hoping to find a library where I would not have to worry about these > details too much... actually this discussion points me again to the fact that Kannel should implement the WSP/WTP client side _too_ in it's libs, instead of only the server side. This shouldn't be to hard, right? Aarno, any work ammount estimation from your side? @Joachim: if you are really interested, feel invited to proceed into this direction and provide patches for it. 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-----