canmove, Confirmed users
725
edits
WebAPI/WebMMS: Difference between revisions
Jump to navigation
Jump to search
→Overview
| Line 3: | Line 3: | ||
On the surface, MMS messages are very similar to multipart HTML emails. One part is responsible for the layout of the message, though MMS uses SMIL rather than HTML. The other parts are attachments, such as text, picture, video, and sound files. Much like in multipart emails, the attachments have "file names" and are referred to by those from the presentation part. | On the surface, MMS messages are very similar to multipart HTML emails. One part is responsible for the layout of the message, though MMS uses SMIL rather than HTML. The other parts are attachments, such as text, picture, video, and sound files. Much like in multipart emails, the attachments have "file names" and are referred to by those from the presentation part. | ||
The API proposal below | The API proposal below tries to reuse as many existing Web technologies as applicable. The SMIL document is exposed as a <a href="https://developer.mozilla.org/en/DOM:document">DOM tree</a> and the attachments as <a href="https://developer.mozilla.org/en/DOM/Blob">Blob</a> objects (or, rather, an extension thereof, akin to how <a href="https://developer.mozilla.org/en/DOM/File">File</a> is an extension of Blob). On a User Agent capable of rendering SMIL, the web application may simply render the DOM right away. On other User Agents, it may use XSLT or some other method to convert SMIL to HTML. | ||
To read the attachments, the web application may use the FileReader API. However, it's not that useful or efficient to have image/audio/video data in memory (e.g. as a typed array). For display purposes the web application just needs a URI that resolves to the data, so that it can point to it in a <video>, <audio>, <img> element. In the simplest case this could be a data: URI, but for large data it might just want to stream the data directly from a file on the disk. (This would be a generally useful feature to provide for all blobs, e.g. when storing multimedia data in IndexedDB.) | To read the attachments, the web application may use the <a href="https://developer.mozilla.org/en/DOM/FileReader">FileReader</a> API. However, it's not that useful or efficient to have image/audio/video data in memory (e.g. as a typed array). For display purposes the web application just needs a URI that resolves to the data, so that it can point to it in a <video>, <audio>, <img> element. In the simplest case this could be a data: URI, but for large data it might just want to stream the data directly from a file on the disk. (This would be a generally useful feature to provide for all blobs, e.g. when storing multimedia data in IndexedDB.) | ||
= API = | = API = | ||