However, this approach might have other benefits -
Allowing Content-Type: multipart to be returned could allow:
A way to generically inline images and other objects without extending
HTML with more <IMG> like tags for other types. If the type is not
understood, a marker should be displayed by the browser.
( Problem: how not to send things that the browser doesn't understand.
If each part has to be parsed and type-checked, this might eliminate
of the advantage of using multipart. )
[ With browser support, this could allow sending audio parts 1,2,3,4,
etc. and start playing part 1 while the rest are being transferred,
automatically playing them in sequence. ]
text/html and text/plain could be alternated, allowing a simple
way of inserting text without having to filter and escape characters
first.
Allow multipart/parallel audio|image and video. Semantics are that
they are intended to be presented together. ( within the "best effort"
of the client. )
[ Functionality of multipart/alternative is already in the client-server
negotiation, so support would be redundant. ]
All of which would, I think, take minimal effort on the server to
implement, but WOULD take a substantial effort for clients to support.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics