tr3mp: hlasilo vsetko co malo reproduktory vo vozidle, teda aj ikarusy :-)) tiez si na to spominam... a tie vtedajsie nahravky sa mi pozdavali viacej ako tie dnesne :-)) inac vodic stlacal iba jeden gombik a ono mu to prehralo zastavku ktora mala nasledovat. Takze v pripade ze niekde na nieco zabudol to bola sranda :-)) a malo to vraj dost velku poruchovost (ani magnetofonu urcite nepridaju na zivotnosti neustale otrasy vo vozidle:-) ) ale sranda je ze z pohladu cestujuceho to fungovalo fakt asi vo vsetkych vozidlach s ktorymi som sa stretol...
To su pekne spomienky, skoda ze sa taka 14Tr nezachovala. Bol by to dnes unikat! 
Dalej si pamatam na linke 10 a 14 este "tee dvojky". Btw., hlasili aj Ikarusy???
.
si
na strane klienta (teda teba s mobilom a PC) sprvis SW, ktory bude generovat requesty na neaku wapstranku (ktora v skutocnosti wapstrankou nebude) asi v nasledujucom formate: http://wap.tvojadomena.sk/DATA kde DATA su samotne prenasane packety od teba. Je nevyhnutne zabezpecit aby ziaden z requestov nebol rovnaky (optimalne tam narvat timestamp, je to nutne napriklad aj kvoli cache ale aj kvoli identifikacii "packetov"), musis si zabezpecit encapsulaciu bajtov (pretoze ty mozes v packete posielat hocaky znak, ale http protokol (alebo cez aku pazu to ide) ti nedovoli do url-ka dat cokolvek a musis posielat requesty aj ked nic nechces (keepalive, aby si drzal linku zivu, lebo server ti nic poslat sam nevie).
strana "servera" bude prijmat prislusne requesty, spracovavat ich a posielat ti odpovede. Odpovede opat musis encapsulovat tak, aby ti to dovolil protokol preniest. (viacej sa mozme pobavit niekedy v reali, som lenivy vela pisat:-))
vyhody: pri dobrej implementacii ti to dokaze zabezpecit sice nekvalitnejsie, ale plnohodnotne spojenie na inet, pri vhodnej konfiguracii mozes mat doma aj verejnu IPcku a neaky server.
nevyhody: vysoky jalovy traffic, nutnost mat niekde vonku stroj ktory servuje requesty.