- From: <passani@eunet.no>
- Date: Fri, 29 May 2009 08:20:38 +0200 (CEST)
- To: "John Hardi" <john.hardi@motricity.com>
- Cc: "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>
John, Can you sure some information about those overrides? where do you get your data about which devices really supports multipart/mixed and which don't? Luca > Luca, > > Thanks for the test sample ;). As previously discussed, device-specific > overrides are needed for this (and a number of other features which device > manufacturers are overly optimistic about). The ³dogfood² site lacks the > full set of overrides that one of our production sites would have, but its > the only site I can point to which doesnıt require authentication. The > intent was to satisfy Tomıs request for an example of how the response was > constructed. Hopefully it accomplishes that. > > John > > Note to self: Next time donıt pick the first device that shows up on the > DeviceAtlas homepage as the UA string to use in lieu of curl ;> > > > On 5/28/09 2:56 PM, "Luca Passani" <passani@eunet.no> wrote: > >> >> 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: >>> Re: ACTION-961: usefulness of multipart-mixed 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 Friday, 29 May 2009 06:21:14 UTC