- From: John Hardi <john.hardi@motricity.com>
- Date: Wed, 27 May 2009 14:44:37 -0700
- To: Tom Hume <tom.hume@futureplatforms.com>
- CC: Magnus Lönnroth <magnus.lonnroth@ericsson.com>, Luca Passani <passani@eunet.no>, Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
- Message-ID: <C6430255.252C%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> 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> >> 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> > 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> > >>>> >>>>> 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> >>>>>> > [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> >>>>>> > > <mailto:Tom.Hume@futureplatforms.com> play: tomhume.org >>>>>> <http://tomhume.org> <http://tomhume.org> >>>>>> > > <http://tomhume.org> >>>>>>> > > >>>>>> > > >>>>>> > >>>>>> > >>>>>> > >>>>> >>>> >>>> > >
Received on Thursday, 28 May 2009 06:44:14 UTC