Cart
[Home] [By Thread] [By Date] [Recent Entries]
AFAIK, there is no support for hardward or software compression of WAP data. Obviously, the hardware can handle compression of voice data, but it looks like the WAP forum supposed that the only compression algorithm to use should be WBXML. What about WBXML ? Well, it just works ! For most WAP developers, WBXML is never seen. The WML -> WBXML transcoding takes place at the WAP gateway ; for you and for me, serving some WAP content is just done by responding a WML document with mimetype text/vnd.wap.wml over HTTP. For most content providers, WBXML is therefore an pretty abstract thing that never gets in the way. Now, for the sake of completeness, we had to write a WBXML encoder in order to support WAP Push. WAP Push on the GSM bearer is done by sending special binary SMS containing WDP packets (WAP rough equivalent of UDP) with a WBXML (not WML) payload. At short or mid-term, the mechanics of building those weird SMS will be assumed by a push-oriented complement of the WAP gateways, named PPG for Push Proxy Gateway. But for now, as PPGs are not publicly deployed by operators, we had to write our own PPG code. Implementing WBXML encoding/decoding is pretty straightforward. Each element and attribute maps to a code in a code page, with bit masks for elements with no content or elements with no attributes. Closing tags are represented by a single byte (WF documents shouldn't need to specify the closing tags names !). Attributes values have many mappings allowing a short encoding of often used attribute values prefixes (like href="http://www."). String encoding is done in the encoding you fancy, just like in XML, though iso-8859-1 and UTF8 are the only encoding required. We implemented WBXML encoding/decoding in a generic way as a SAX filter, and we can plugin various code pages to support various input/output DTDs like WML of course, but also SI, SL and CO, which are short notification or cache manipulation messages. WBXML is not restricted to WML, it can handle any XML content whose schema is fully known beforehand, provided that you write a bytecode mapping for ite. What we didn't do is compare the efficiency of WBXML vs. gzip or other compression schemes. That may be an interesting thing to do since we already have the code to do both (thanks to the java.util.zip.GZIP[In|Out]putStream classes). We haven't done it yet because we just had to support WBXML, no question about it :). What I find interesting is that a WBXML document can easily be manipulated in serial or random access mode ; once a schema is hardwired, there is no need to manipulate full-length strings, a simple switch statement over an integer value can be used by a renderer to discover the content of a document. I suppose this allows the rendering code to be much more lightweight than a full XML + gzip compression scheme, where the code would have to handle gzip decompression as well as full-length string comparison for element and attribute names. Likewise, WML is said to be designed to allow a one-pass rendering of a document, that's why tables have a mandatory "cols" attribute, for example. The WAP Forum has not focused only on bandwidth, they took care of the ease and compacity of implementations. This allows WAP browsers to run on cheaper and more energy-saving hardware. The less Mhz the CPU require, the longer the battery will last. This may seem a foolish point but energy saving is a very important point for mobile manufacturers. The fun thing with WAP is that it mixes XML and the Web with embedded design concerns. I agree, though, that some design choices in WAP were rather strange. For example, they designed a brand new image format, with absolutely no advantage over existing ones. This was a pain in the ass in the early days when imaging tools didn't have support for the WBMP format, forcing us to write convertors ourselves (which we used for on-the-fly image conversion anyway). Some people were baffled by the way the WAP Forum scorned the XBM format to build a new one, not quite the same but very near, with absolutely no added value. WAP 2.0 [1] will change a lot of all this. WAP 2.0 indeed keeps all the "legacy" of WML 1.2 (i.e. all the WAP specific network layers) but will also support the plain old Internet network layers : TCP/IP and HTTP, GIFs and PNGs, and JPEGs, without requiring a WAP gateway to be deployed. The need for a WAP gateway has been criticized a lot, especially in the short lapse of time where mobile operators tried to prevent users from changing their WAP gateway by distributing WAP-locked phones (with which you were bound to use the operators' WAP gateway). The fact that all WAP data exchange must go through a central server controlled by the mobile operator was seen as an attempt by the mobile operator to lock the market. But the truth is that a WAP gateway can be useful, or even required. It can be useful due to its capacity to cache content, even if large scale caching is doubtfully efficient. The compression brought by WBXML is also interesting, and the fact that a gateway was is providing the required logic for WML to WBXML translation allows people to produce WAP services easily. Those are technical reasons, though, and in the euphory of early 2000, when people thought that 2 Mbps bandwidth would be reached in the next year, the "they-want-to-own-us" paranoia was de rigueur. Anyway, it can, and maybe will, be required to have a central access point when revenue sharing is implemented. As the mobile operator is the entity that charges the users, it must have a way to log the usage of pay-per-use services to be able to charge them and share revenues with the proper service provider. I really think revenue sharing is the best way to see the birth of high-quality mobile services and killer apps. Revenue sharing is like the universal micro-payment solution that the Internet has been missing until now. But revenue sharing is necessarely centralised by the different mobile operators ; the fact that we're in not mobile phone market, not the Internet, makes it feasable. Introducing revenue sharing at the ISP level would shock a lot of people, I guess. Regards, Nicolas -----Message d'origine----- De : Mike Champion [mailto:mc@x...] Envoyé : lundi 11 mars 2002 19:16 À : xml-dev@l... Objet : Re: RE: What happened to WAP 3/11/2002 10:50:32 AM, Nicolas LEHUEN <nicolas.lehuen@u...> wrote: >To conclude, we should not look at pure technical reasons to explain the >demise of WAP. The problem is mainly rooted in the dynamics of the mobile >phone market. Thanks for the great summary of WAP technology/business! I'm still unclear on my question in the other thread, though: Do WAP phones have any hardware-level or OS-level data compression? I'd also like to hear Nicolas' take on the significance of WBXML in the context of the WAP reality today.
|
