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

Re: ACTION-961: usefulness of multipart-mixed

From: <passani@eunet.no>
Date: Fri, 29 May 2009 08:20:38 +0200 (CEST)
Message-ID: <4555.93.45.126.135.1243578038.squirrel@webmail.comnet.no>
To: "John Hardi" <john.hardi@motricity.com>
Cc: "Mobile Web Best Practices Working Group WG" <public-bpwg@w3.org>

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 Friday, 29 May 2009 06:21:14 UTC

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