W3C home > Mailing lists > Public > public-bpwg@w3.org > May 2009

Re: ACTION-961: usefulness of multipart-mixed

From: Luca Passani <passani@eunet.no>
Date: Thu, 28 May 2009 11:59:08 +0200
Message-ID: <4A1E606C.7020003@eunet.no>
To: Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Tom Hume wrote:
> John
>
> Do you have some example code for this sort of thing, or can you point 
> me at some?

yes, that's the key question to ask when it comes to multipart, 
regardless of high-level discussions on its usefulness. In order for 
multipart to be a best practice, it needs to be adoptable and widely 
adopted by developers. All we can find on the web today are pre-historic 
traces of tools and examples, but hardly any live example of it (I 
wouldn't know of one).

Tangently to this discussion, I would be curios to see a multipart 
deployment and observe how transcoders handle it. As recently as 
yesterday, I observed Novarra@VodafoneUK fail miserably in the presence 
of an HTTP 301 redirect ("could not understand response") where the same 
device was working smoothly with all other operators.
In this context, I suspect that observing novarra handle multipart would 
be fun, so if you have a reference, please post it.

Luca






>
> Tom
>
> 2009/5/27 John Hardi <john.hardi@motricity.com 
> <mailto: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>
>                         > >
>                         >  >
>                         >
>                         >
>                         >
>
>
>
>
>
>
>
>
> -- 
> 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 09:59:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:00 UTC