- From: Luca Passani <passani@eunet.no>
- Date: Thu, 28 May 2009 11:59:08 +0200
- 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