- From: Luca Passani <passani@eunet.no>
- Date: Thu, 28 May 2009 23:56:07 +0200
- To: John Hardi <john.hardi@motricity.com>
- CC: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
- Message-ID: <4A1F0877.3010401@eunet.no>
John, I just happened to have a N95 8Gb in my drawer, so I hit your site with it. The XHTML was there, but none of the pictures were loaded. This checks out with what I was experiencing with multipart/mixed on Nokia devices back in 2003-2004 with Nokia 3650 and 6600, which, in turn, made me conclude that accept header and UAProf were a totally unreliable source of information to decide which devices can manage multipart. I am sure that Ericsson does it well because they do actual testing with devices. Luca John Hardi wrote: > Tom, > > We developed it in-house and I don't have an open source code example > I can point you to. If you want to see it in operation, the "dogfood" > site for our platform m.mcore.com has multipart enabled. If you go > there with a multipart-capable device, you should get a multipart payload. > > If you have curl, this should get you today's home page in multipart: > curl -H "Accept: > text/html,application/xhtml+xml,application/xml,multipart/mixed" -A > "Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaN95_8GB-3/20.2.005 > Profile/MIDP-2.0 Configuration/CLDC-1.1 ) AppleWebKit/413 (KHTML, like > Gecko) Safari/413" http://m.mcore.com/motricity/ptl/px/home/i.aspx > > An unscientific snapshot from one set of web servers showed a bit over > half the mobile pages being delivered in multipart. > > As I mentioned in my original post, the degree of difficulty for > multipart may make it unsuitable as a "best practice" recommendation. > It's use is probably most suitable for sites where performance is > critical and worth the investment. But I did want to address the > misconceptions that multipart being archaic or only being used in > network components. It is a viable technique which addresses some of > the considerations of sections 3.4.5 and 3.5.2 of the best practices. > > John > > On 5/28/09 12:38 AM, "Tom Hume" <tom.hume@futureplatforms.com> wrote: > > John > > Do you have some example code for this sort of thing, or can you > point me at some? > > Tom > > 2009/5/27 John Hardi <john.hardi@motricity.com> > > Tom, > > >From a CP POV, one would use it to improve performance of > pages which have a number of frequently changing dynamic > content parts (i.e. images). > > By using the absolute URI/URL of a resource for the > Content-Location header URI of its part , you shouldn't need > to change the references in the base (X)HTML part. This > allows a packaging filter on the front of your web server's > page processing to handle it in a fairly generic fashion. In > general, I think this is consistent with RFC 2557. As for > support, it's fairly broad --- certainly more broad than CSS2, > though that hopefully won't remain the case. > > John > > > On 5/27/09 12:46 PM, "Tom Hume" <tom.hume@futureplatforms.com > <http://tom.hume@futureplatforms.com> > wrote: > > John > > How, from a content provider POV, does one make use of > this? How would I refer to a specific resource within a > multi-part/mixed response - using some sort of URL scheme? > And how well supported is this, in your opinion? > > Tom > > 2009/5/27 John Hardi <john.hardi@motricity.com > <http://john.hardi@motricity.com> > > > Magnus & Tom, > > While not a regular contributor, I did want to add a > bit of perspective on this topic. > > First I must concur with Magnus that MIME multipart is > still in use and can improve the user's experience in > page load times as a round-trip latency reduction > tool. While it can be a network optimization as > Magnus describes, the benefit is actually greater if > done at the page source, thus eliminating the multiple > round trip latencies between the mobile network > gateway / proxy and the CP as well as from the handset > across the mobile network. > > Sprites / Composite images are not comparable; they > only offer improvement for static, decorative images. > If the multiple images/parts of a page are dynamic > content (news photos, album art, etc.) multipart still > provides benefit where sprites would not. It also > provides the delivery performance benefits of embedded > CSS with the flexibility of a linked style sheet. > > Being a content type, use of multipart is independent > of Content-Encoding. So it's not required that > multipart payloads be gzipped, though doing so may be > worthwhile where it is also supported by the device. > > There are cases, as Luca describes, where devices > advertise support in HTTP headers but don't > necessarily handle it well. So device awareness and > the ability to override the devices' claim of support > is necessary. However, I don't believe this is > significantly different from other advertised device / > browser capabilities (CSS2 positioning, for example). > > The degree of difficulty may make multipart debatable > as a best practice, but I don't consider it irrelevant > "from the content provider's point of view". > > Hope this helps... > > John Hardi > Dir, Technology Strategy > Motricity, Inc. > > > On 5/27/09 12:22 AM, "Magnus Lönnroth" > <magnus.lonnroth@ericsson.com > <http://magnus.lonnroth@ericsson.com> > <http://magnus.lonnroth@ericsson.com> > wrote: > > Yes, I'm referring to HTTP responses. A proxy is > needed. URL-rewriting is needed. I'm not sure if > the context for my response was appropriate - I > was just reacting to the previous statements > saying that packaging content in multi-part MIME > digests was kind of obsolete. From the content > provider's point of view MIME multi-part digests > are irrelevant and have probably always been so. > From the service provider's point of view it's > still an important network level optimization. But > it should be completely transparent and hence most > likely not part of a best practices discussion. > Sorry if I'm confusing matters. > > /Magnus > > > > ------------------------------------------------------------------------ > *From:* Tom Hume > [mailto:tom.hume@futureplatforms.com] > *Sent:* Wednesday, May 27, 2009 8:51 AM > *To:* Magnus Lönnroth > *Cc:* Luca Passani; Mobile Web Best Practices > Working Group WG > *Subject:* Re: ACTION-961: usefulness of > multipart-mixed > > > Magnus > > > Are you referring to using multi-part/mixed > for HTTP responses from a web server? > > > > If so, can you explain how resources within a > multi-part/mixed HTTP response are referred > to from each other, or from outside the response? > > > > Tom > > > 2009/5/27 Magnus Lönnroth > <magnus.lonnroth@ericsson.com > <http://magnus.lonnroth@ericsson.com> > <http://magnus.lonnroth@ericsson.com> > > > > Hi, delivering multi-part MIME digests > has been and still is an important part > of optimizing performance in our > installations. The main reason for > developing this is the latency in 3g > networks compared to wired broadband or > wi-fi. It must of course be fully > transparent and not affect content or > content design in any way. One important > aspect is to have detailed knowledge of > the device's own caching capabilities and > support for digests so that subsequent > deliveries not include content that is > already available (cached) on the > handset. If full digests are delivered > with each request I agree that the > benefit is questionable. But if you have a > good implementation with device knowledge > the improvement is significant. > > thanks, > > Magnus Lönnroth > Head of Development > Service Delivery & Provisioning, Ericsson /// > > > > > > -----Original Message----- > > From: public-bpwg-request@w3.org > <http://public-bpwg-request@w3.org> > <http://public-bpwg-request@w3.org> > > [mailto:public-bpwg-request@w3.org] On > Behalf Of Luca Passani > > Sent: Tuesday, May 26, 2009 11:49 PM > > To: Mobile Web Best Practices Working > Group WG > > Subject: Re: ACTION-961: usefulness of > multipart-mixed > > > > > > Multipart was a useful mechanism to > deliver a full page in one shot. > > Vodafone leveraged multipart for its > vodafone live service on > > devices which supported it. Multipart > allowed for snappy (or at least > > "2002-snappy") display of the top page, > which looked great as > > compared to everything WAP had > represented until that day. > > There was no way to know whether > multipart was properly > > supported by a device, except testing on > that device. > > Notably, many devices declared multipart > support in headers > > and UAProfs, but the information was not > reliable at all. I > > recall that I never managed to get > multipart to work on a > > Nokia device (still vaguely curious about > whether there was a way). > > Vodafone maintained its own db with this > info for devices in > > its portfolio. Not sure if they still do. > Probably not. Too > > much effort for too little value. > > > > 3G networks and faster browsers make the > use of multipart > > much less relevant, particularly because > pages become much > > harder to build and maintain if > multipart is in the middle. I > > made space for multipart in WURFL back > in 2003, but the > > community did not really follow: nobody > was using it obviously. > > > > Luca > > > > Tom Hume wrote: > > > I took an action a couple of weeks ago > to look into multipart/mixed > > > MIME types, to see if they might be > usefully related to > > sections 3.4.6 > > > and 3.4.7 of MWABP[1] (ACTION-961). In > particular it would seem > > > helpful to be able to bundle many > images up into a single HTTP > > > request, avoiding unnecessary round > trips to download a set > > of them. > > > The current advice is to combine > related images into a single file, > > > download this, and use CSS positioning > and clipping to > > render parts of > > > this file. multipart/mixed would > provide another route for > > downloading > > > many resources at once. > > > > > > The only reference I can find to mobile > usage of multipart-mixed is > > > this tutorial from OpenWave: > > > > > > > > http://developer.openwave.com/dvl/support/documentation/technical_note > > > s/multipart.htm > > > > > > From running this experiment with > desktop browsers, multipart-mixed > > > doesn't seem to be well supported. > I've set up an HTTP response > > > matching the above and found that: > > > > > > - Firefox and Opera render the second > page in the message > > > - Safari doesn't recognise it as HTML > and downloads it > > > - IE renders content from both pages > > > > > > I've also got a question of how, from > within CSS or similar, an > > > individual part of a multipart-mixed > message might be uniquely > > > referred. The only reference I can find > for a URL-scheme for such > > > things is a scheme for references to > body parts of messages, which > > > date back to 1997 or earlier, and seem > to be designed with > > HTML email > > > in mind: > > > http://www.ietf.org/rfc/rfc2392.txt > > > > > > Beyond the Openwave tutorial, and the > following tool which > > exists to > > > create these messages: > > > > > > http://www.umts-tools.org/docs/multipart/ > > > > > > ...I can't find any other reference to > them; and it's not a > > technique > > > I've come across myself. Am I missing > something obvious here? From > > > where I'm sitting this looks like a > barely-used, poorly- supported > > > technique which I'd hesitate to > consider a best practice - > > though it > > > might be handy if it worked. > > > > > > Tom > > > > > > [1] > http://www.w3.org/TR/2009/WD-mwabp-20090507/#d1e8981 > > > > > > -- > > > Future Platforms: hungry and foolish > since 2000 > > > work: Tom.Hume@futureplatforms.com > <http://Tom.Hume@futureplatforms.com> > <http://Tom.Hume@futureplatforms.com> > > > <mailto:Tom.Hume@futureplatforms.com> > play: tomhume.org <http://tomhume.org> > <http://tomhume.org> <http://tomhume.org> > > > <http://tomhume.org> > > > > > > > > > > > > > > > > > > >
Received on Thursday, 28 May 2009 21:56:45 UTC