tag:blogger.com,1999:blog-17500930.post1015971259621799615..comments2024-03-20T22:57:03.923+00:00Comments on Dean Bubley's Disruptive Wireless: So exactly what is a byte when transmitted via a mobile data service?Dean Bubleyhttp://www.blogger.com/profile/05719150957239368264noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-17500930.post-50426299039087065332007-01-29T13:42:00.000+00:002007-01-29T13:42:00.000+00:00Re: additional headers in HTTP requests:
In fact,...Re: additional headers in HTTP requests: <br />In fact, some popular mobile phones send so much more device capability information that it may be seen as an overhead problem.<br />So yes, it is mainly up to Web application developers to use this to adapt the Web content. However, the provided information varies strongly between phone vendors or even models, and thus may create an opportunity for some middleware / Web development platform.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17500930.post-85332123178341714332007-01-24T21:44:00.000+00:002007-01-24T21:44:00.000+00:00It's not the CPUs, though, it's the data transfer ...It's not the CPUs, though, it's the data transfer costs. The casual users, the ones that the networks <i>want</i> to get hooked on mobile Internet services, typically aren't on flat-rate data plans (especially, say, in the UK where a huge proportion of mobile users are pre-pay customers) will care about the per-byte costs, because ultimately they're paying for it.<br /><br />Add to that the fact that most web agencies are still ignoring web standards and churning out horrifically heavy mark-up and are often ignorant of proper (device-agnostic) practices, which means that pages are a <b>bucketload</b> bigger than they need to be to express the content that they hold, and pay-per-byte users suffer because of it.<br /><br />On top of that, non-3G users have to deal with high-latency links wherein each request/response round-trip is <b>slow</b>, even if the bandwidth available is relatively plentiful: pipe-lining the requests into a custom protocol that not only compresses the data (to save costs) but also fetches and sends the page pre-requisites server-side automatically (to speed things up) is fairly benefit-heavy.<br /><br />The CPUs haven't been the issue for mobile UAs for a long time, not unless you want a Flash-heavy desktop-style ‘experience’ on your phone (arguably, this is what would attract people, but the applets would have to be properly designed for mobile platforms in any case… it ceases to be a web browsing issue fairly quickly).Mohttps://www.blogger.com/profile/05086174607811617514noreply@blogger.comtag:blogger.com,1999:blog-17500930.post-49385194180735981622007-01-24T09:56:00.000+00:002007-01-24T09:56:00.000+00:00Regarding how to recognize screen resolution,
Ple...Regarding how to recognize screen resolution,<br /><br />Please check this out:<br />http://en.wikipedia.org/wiki/UAProf<br /><br />So mobile terminals typically put an URL to the user agent profile file in the HTTP request. If the server doesn't have a cached version of the file it can receive it from the URL.<br /><br />Here you can see some examples of the depth of the information contained in UAProf - it's quite extensive:<br />http://w3development.de/rdf/uaprof_repository/<br /><br />BUT, personally I think with current relatively CPUs in the mobile devices & 3G it would be wrong to mangle the pages in the network.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-17500930.post-88072134955989949992007-01-23T23:31:00.000+00:002007-01-23T23:31:00.000+00:00It's not MIME that adds the overhead per se, but t...It's not MIME that adds the overhead per se, but the fact that attachments are typically <a href="http://en.wikipedia.org/wiki/Base64">base64</a>-encoded to make them 7-bit-clean.<br /><br />HTTP is pretty extensible. Many specialised agents already send device information headers that can be picked up by any proxy along the way, or indeed the web server. All it'd take would be headers reading:<br /><br />X-Screen-Res: 352x412@16<br />X-Proxy-Compress-Preference: medium<br /><br />The developer of the user-agent can make it send whatever it likes. (iMode clients send all manner of stuff along these lines, for example, as does NetFront on the PSP)..Mohttps://www.blogger.com/profile/05086174607811617514noreply@blogger.comtag:blogger.com,1999:blog-17500930.post-33670461386563016292007-01-23T22:52:00.000+00:002007-01-23T22:52:00.000+00:00Hmmm. Interesting point on the MIME encoding, I di...Hmmm. Interesting point on the MIME encoding, I didn't know that - shame the Yahoo support people didn't know the answer when I'd queried it the observation in the past. Fair point on the SGSN/GGSN charging too, although what happens with multicast when MBMS arrives?<br /><br />I've had several separate conversations in the past 3 months discussing the potential for caching content at the edge of the cellular network, or doing an Akamai-style GGSN bypass type approach. Can't say I'm convinced, but it's definitely being talked about.<br /><br />I'm not convinced about the screen res being predictable - can HTTP really say "this is an Opera browser running on a 352x412 screen with 18-bit colour depth, so please don't compress images too much"?Dean Bubleyhttps://www.blogger.com/profile/05719150957239368264noreply@blogger.comtag:blogger.com,1999:blog-17500930.post-60038484795867481102007-01-23T12:32:00.000+00:002007-01-23T12:32:00.000+00:00Sorry to say but your posting seemed quite clueles...Sorry to say but your posting seemed quite clueless. Some comments:<br /><br />- Network will bill you based on the compressed content, of course. Charging is done typically by SGSN or GGSN.<br />- Content is never cached by basestation. I don't understand what you meant with that?<br />- EMail attachments use MIME encoding which causes overhead somewhere around 30%<br />- Screen resolution or type of user client can in some cases seen from HTTP requestAnonymousnoreply@blogger.com