[
Lists Home |
Date Index |
Thread Index
]
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@xegesis.org]
Envoyé : lundi 11 mars 2002 19:16
À : xml-dev@lists.xml.org
Objet : Re: RE: [xml-dev] What happened to WAP
3/11/2002 10:50:32 AM, Nicolas LEHUEN <nicolas.lehuen@ubicco.com> 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.
|
