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>

> 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_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
> > > <mailto:Tom.Hume@futureplatforms.com> play: tomhume.org
> > > <http://tomhume.org>
> > >
> > >
> >
> >
> >
>
>


-- 
Future Platforms: hungry and foolish since 2000
work: Tom.Hume@futureplatforms.com play: tomhume.org