Re: ACTION-961: usefulness of multipart-mixed

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> 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>
>
> 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> > 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<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> >
>
>
> 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>
> >  [mailto:public-bpwg-request@w3.org <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>
>  >  > <mailto:Tom.Hume@futureplatforms.com <Tom.Hume@futureplatforms.com>>
>  play: tomhume.org <http://tomhume.org>  <http://tomhume.org>
>  >  > <http://tomhume.org>
> > >
> >  >
> >
> >
> >
>
>
>
>
>
>


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