From dee8939277e0fb695fb23e0dcc98559cb9996d16 Mon Sep 17 00:00:00 2001 From: Tobias Markmann Date: Wed, 6 Oct 2010 00:09:10 +0200 Subject: [PATCH 1/2] Fix use of definition lists. --- xep-0286.xml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/xep-0286.xml b/xep-0286.xml index 17658c5c..2a7f2618 100755 --- a/xep-0286.xml +++ b/xep-0286.xml @@ -113,27 +113,45 @@

As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:

+
Transmit no data.
Transmitting costs significant power, and moreover raises the radio state. Not transmitting will allow it to maximize the time spent in the low-cost Idle state.
+
+
If you must transmit, then transmit only a small volume.
If there is only a small amount of data transmitted - less than 128 octets typically - the radio will only raise to FACH, which is significantly cheaper than DCH.
+
+
If you must transmit, then compress as hard as possible.
Since individual octets have an associate power - and often financial - cost, it's worth maximizing the compression algorithm, even if the volume of traffic will raise to DCH.
+
+
If you have transmit a lot, then do a lot
If the radio is raised to DCH anyway, then you may as well go fetch that avatar you were missing, since you're chewing through power anyway.
+
+
If you receive, then transmit
If your peer raises the radio state, you may as well use it.
+

And for servers, similar rules apply:

+
Send no data.
Sending data will cause the handset to be raised out of Idle. This immediately costs massively higher power.
+
+
If you must send, send tiny bits.
Sending small enough data maximizes the likelyhood that the devices radio will only be raised to FACH levels.
+
+
If you receive, then send anything you have.
Receiving data indicates that the radio is active - it'll stay active for some time, so sending data doesn't incur the overhead of raising the radio state, and won't increase power drain on the handset.
+
+
If you must send when not receiving, send plenty.
Sending data will raise the radio's state - unless you can tell this will only raise it to FACH, it's worth sending as much as possible.
+

Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.

From b4412526ef03a536642ce261d1d4bab0ea1c751b Mon Sep 17 00:00:00 2001 From: Tobias Markmann Date: Wed, 6 Oct 2010 00:21:08 +0200 Subject: [PATCH 2/2] Improving table layout and general LaTeX compatibility. (Thanks to Florian Zeitz) --- xep2texml.xsl | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xep2texml.xsl b/xep2texml.xsl index d2b7e044..1e068de2 100755 --- a/xep2texml.xsl +++ b/xep2texml.xsl @@ -99,6 +99,8 @@ \newcommand{\XEPNumber}[0]{} \newcommand{\XEPVersion}[0]{} +\newcolumntype{L}{>{\raggedright\arraybackslash}X} + \fancyhead[L,L]{\includegraphics[totalheight=10pt]{xmpp.pdf} \slshape \leftmark} \fancyfoot[C,C]{\thepage} @@ -225,7 +227,7 @@ - + \linewidth lXX & \\