RE: ACTION-961: usefulness of multipart-mixed

I admit that with the new hi-speed HSDPA/HSUPA 3g networks we get around 80 ms latency in theory, perhaps twice that in practice, which more or less removes the need for multi-part MIME digests as a delivery optimization method. And although these are being deployed quickly, a bad signal or a busy cell can probably still put you right back to where we were 5 years ago with latencies in excess of 1000 ms. So anyway, I only think we disagree on the timing - I'm not prepared to throw multi-part MIME digests in the context of reducing latency out the window just yet, but I agree that eventually it will no longer be needed for this purpose.

On a side-note, I can assure that Ericsson makes a heck of a lot more selling HSDPA/HSUPA network upgrades than supporting multi-part MIME digests :)

Magnus Lönnroth
Head of Development
Service Delivery & Provisioning, Ericsson ///

> -----Original Message-----
> From: public-bpwg-request@w3.org 
> [mailto:public-bpwg-request@w3.org] On Behalf Of Luca Passani
> Sent: Wednesday, May 27, 2009 3:11 PM
> To: Mobile Web Best Practices Working Group WG
> Subject: Re: ACTION-961: usefulness of multipart-mixed
> 
> 
> I disagree that multi-part makes such a huge difference for 
> 3G phones. 
> It does not.
> 
> If you build your pages by:
> 
> 1)  allocating space for the pictures in the img tag 
> (height/width attributes),
> 
> 2) adopting well-formed markup and
> 
> 3) keeping CSS in the page (and not external as BP wrongly 
> recommends),
> 
> then users will perceive the page as equally fast, or even 
> faster, since XHTML loads faster than the full bundle of  
> XHTML/CSS/Pictures.
> 
> I understand that some companies want to present multipart 
> support as something that gives extra value to their 
> platform, but for regular developers supporting multipart 
> introduces way too many hurdles to make sense. Even assuming 
> they have a framework to automatize the packaging of their 
> pages, which devices support multipart and which do not is 
> NOT public information, i.e. they have no path to creating 
> multipart which works reliably.
> 
> In short, I would be disappointed if W3C recommended that 
> buying from Ericsson is a best practice :)
> 
> Luca
> 
> Magnus Lönnroth wrote:
> > 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
> >> [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_not
> >> e
> >>     
> >>> 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
> >>> <mailto:Tom.Hume@futureplatforms.com> play: tomhume.org 
> >>> <http://tomhume.org>
> >>>
> >>>
> >>>       
> >>
> >>     
> >
> >
> >   
> 
> 
>

Received on Thursday, 28 May 2009 08:11:36 UTC