- From: John Hardi <john.hardi@motricity.com>
- Date: Mon, 01 Jun 2009 07:33:09 -0700
- To: <passani@eunet.no>
- CC: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Luca, We start with what's in the Accept header. But that can be overriden by a device profile attribute akin to the multipart_support attribute you have in WURFL. The override can be positive or negative (i.e. True even though the device doesn't advertise in Accept, or False even though it does). As for how we get decide to override, primarily it's through our own handset profiling and/or user problem reports. John On 5/28/09 11:20 PM, "passani@eunet.no" <passani@eunet.no> wrote: > > 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 Monday, 1 June 2009 14:33:46 UTC