Draft Report
Copyright © 2012 W3C® (MIT, ERCIM, Keio), published by the Web-based Signage Business Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.
This Profile defines requirements for storing downloaded files and playing the stored contents in the terminal
Web-based Signage is basically assumed to be online. But some signage terminals are connected to a narrowband network, some signage terminals use a time-limited network. Especially when playing videos, instability of the the network quality could cause a service outage.
Storing contents and playing the stored contents ensure that contents are played reliably regardless of the state of the network, the network traffic is reduced, and web-based signage services are cost-effective. Storing contents and playing the stored contents are essential for web-based signage.
This specification was published by the Web-based Signage Business Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this document. [RFC2119]
This section is non-normative.
The "Architecture and Requirements for Web-based Signage Player" defines precise requirements for web-based signage players.
The Architecture and Requirements for Web-based Signage Player consist of a number of profiles. Basically, web-based signage is based on the core profile. As necessary, web-based signage systems adopt the other profiles additionally.
These profiles are also intended to be used as product specification sheets of web-based signage products for vendors, RFP (request for proposal) used by the signage operators to request SDCs (Systems Development Corporations) to develop a web-based signage system , etc.
Through these activities, the Web-based Signage Business Group aims to:
We believe that web-based signage contribute to cost-efficiencies and rich functionalities in the digital signage industry. As a result, we hope that the digital signage industry will grow up increasingly.
Web-based signage is digital signage whose contents are created using web-technologies. Besides, it has a capability of connecting to a network. It is not a matter whether the network is the Internet or not. The web-based signage includes the terminal in an intranet.
A player plays contents for web-based signage. It is a set of an application and a runtime. This document is not aimed for limitation of underlying hardware and the operating system. Basically, web-based signage is based on the core profile. As necessary, web-based signage systems adopt the other profiles additionally.
An application is comprised of the software such as frameworks or the libraries for signage. An application is a set of JavaScript programs and style sheets and HTML. An application is run on a runtime, fetches contents form a content server, then plays the contents appropriately. The architecture and the functions of the applications will be prescribed as the features for web-based signage.
A player uses the functions and the expressions which the underlying runtime provides. Basically, they are specified in HTML5 in wide sense. This document does not restrict the use of the functions which are out of scope of this document. Applications may use such functions and expressions.
A runtime is a common web browser (e.g. webkit-based browsers, Firefox, IE, etc.) or a web-based application runtime (e.g. Firefox OS, Tizen, Windows 8, etc.) installed in tablets, PCs, STBs, TV (most of current high-end TV products implement a web-browser), etc. On the other hand, it is not a dedicated subset or subset-based derivation of HTML5 in wide sense. Basically, runtime offers functions called HTML5 in the wide sense. Basically, the specifications of HTML5 in wide sense are be specified particularly by W3C.
This document mainly defines the requirements for applications. But it implicitly includes the requirements for runtimes because applications must use web technologies implemented in runtimes to meet the requirements for applications. Therefore, this document defines the requirements for players (applications and runtimes).
Contents mean everything shown on a digital signage display. The contents of web-based signage are served by a content server through a network. They consist of HTML, CSS, and JavaScript. Some contents are possibly created using XML-based technologies which are embedded in HTML, such as SVG. [SVG]
The application gets a content file from the CDN using XMLHttpRequest. Setting the responseType attribute of the XMLHttpRequest object to "blob", the application gets the file as a Blob object.
loadVideoFile();
// Download a video file as a blob object using XHR
function loadVideoFile() {
var xhr = new XMLHttpRequest();
xhr.open("GET", "v.mp4");
xhr.responseType = "blob";
xhr.onload = function() {
if(xhr.status === 200) {
var blob = xhr.response;
// Save the blob to the storage
if(window.indexedDB) {
saveBlobIdb(blob);
} else if(window.webkitRequestFileSystem) {
saveBlobFsys(blob);
}
}
};
xhr.send();
}The application can use Indexed Database API or File API: Directories and System to store files. These APIs allow scripts to store Blob objects directly.
The runtime must support XMLHttpRequest. The runtime must support Indexed Database API or File API: Directories and System. Besides the runtime must support storing Blob objects directly, which is specified in File API. [XHR] [IDB] [FILEDIR] [FILE]
// Save the blob in the DB
function saveBlobIdb(blob) {
var db_name = "mydb";
var store_name = "mystore";
var file_name = "v.mp4";
// Open the DB
var idb = window.indexedDB;
var openreq = idb.open(db_name, 1);
// Create a object store
openreq.onupgradeneeded = function(event) {
var db = event.target.result;
var params = { keyPath: "filename" };
var store = db.createObjectStore(store_name, params);
};
// Save a Blob object
openreq.onsuccess = function(event) {
var db = event.target.result;
var transaction = db.transaction([store_name], "readwrite");
var store = transaction.objectStore(store_name);
var putreq = store.put({ "filename": file_name, "data": blob});
putreq.onsuccess = function () {
// Get the blob from the DB
window.setTimeout(function() {
getBlobIdb(file_name);
}, 3000);
};
};
}// Save the blob in the File System
function saveBlobFsys(blob) {
var file_name = "v.mp4";
// Open the file sytem
window.webkitRequestFileSystem(window.TEMPORARY, 10*1024*1024, function(fs) {
// Create a file in the root
fs.root.getFile(file_name, { create: true }, function(fileentry) {
// Write the data to the file
fileentry.createWriter(function(writer) {
writer.write(blob);
writer.onwriteend = function() {
// Get the blob from the file system
getBlobFsys(file_name);
};
});
});
});
}Note that File API: Directories and System has been deprecated, the detailed specification has been deleted from the official public draft. Now you can see the detailed specification in the editor's draft.
Now File API: Directories and System has been replaced by FileSystem API. In the future, the applications are encouraged to use FileSystem API instead of File API: Directories and System. [FILESYS]
If the application uses Indexed Database API to store files, it gets the file as a Blob object. The application creates a blob URL from the Blob object using URL.createObjectURL() method, which is specified in File API. Then The application creates a appropriate HTML element (e.g. video element if a video file, audio element if a audio file, img element if a image file) and sets the src attribute to the blob URL.
// Get the blob from the DB
function getBlobIdb(file_name) {
var db_name = "mydb";
var store_name = "mystore";
// Open the DB
var idb = window.indexedDB;
var openreq = idb.open(db_name, 1);
// Get the blob object
openreq.onsuccess = function(event) {
var db = event.target.result;
var transaction = db.transaction([store_name], "readonly");
var store = transaction.objectStore(store_name);
var getreq = store.get(file_name);
// Create a blob URL and play the video
getreq.onsuccess = function(event) {
var rec = event.target.result;
var blob_url = window.URL.createObjectURL(rec["data"]);
playVideoIdb(blob_url);
};
};
}
// Play the video
function playVideoIdb(url) {
// Create a video element
var el = document.createElement("video");
el.src = url;
document.body.appendChild(el);
// Play the video
el.play();
// When the playback ends, remove the video element
el.addEventListener("ended", removeVideoElementIdb, false);
}
// Remove the video element
function removeVideoElementIdb(event) {
var el = event.target;
// Remove the event listener
el.removeEventListener("ended", removeVideoElementIdb, false);
// Release the blob URL
window.URL.revokeObjectURL(el.src);
// Remove the video element
el.parentNode.removeChild(el);
}The application is strongly encouraged to call URL.revokeObjectURL() to release the blob URL when the relevant HTML element was removed from the document. If the application removes the element associated with the blob URL without releasing the blob URL, the garbage collection of the JavaScript engine in the runtime doesn't work as expected. It causes memory leak and prevents stable long run as a signage terminal.
The runtime must support URL.createObjectURL() method. [FILE]
If the application uses File API: Directories and System to store files, it can get a file URL. Though the application can get a file as a Blob object, it doesn't need to do. If the application shows a file using the img element or the video element, the file URL is enough for the purpose.
// Get the blob from the file system
function getBlobFsys(file_name) {
// Open the file sytem
window.webkitRequestFileSystem(window.TEMPORARY, 10*1024*1024, function(fs) {
// Get the file
fs.root.getFile(file_name, { create: false }, function(fileentry) {
// Create a file URL and play the video
var file_url = fileentry.toURL();
playVideoFsys(file_url);
});
});
}
// Play the video
function playVideoFsys(url) {
// Create a video element
var el = document.createElement("video");
el.src = url;
document.body.appendChild(el);
// Play the video
el.play();
// When the playback ends, remove the video element
el.addEventListener("ended", removeVideoElementFsys, false);
}
// Remove the video element
function removeVideoElementFsys(event) {
var el = event.target;
// Remove the event listener
el.removeEventListener("ended", removeVideoElementFsys, false);
// Remove the video element
el.parentNode.removeChild(el);
}In practice, A web-based signage system consists of not only players but also content delivery servers and content management systems. In some cases, script files associated with the application could be hosted in other servers. That is, the origins of contents and application are not necessarily same.
XMLHttpRequest normally does not allow applications (scripts) to fetch files whose origin is different from the application. To do so, the runtime and content delivery servers must support Cross-Origin Resource Sharing. The conformant runtime must support at least Origin Request Header and Access-Control-Allow-Origin specified in Cross-Origin Resource Sharing. [CORS]
When the application stores resource files (e.g. video file, image files), the application needs to know the total size, used size, and free size of the storage.
Quota Management API meets this requirements. Quota Management API allows scripts to get the total size and the used size of the storage. The free size is available subtracting the free size from the total size.
If runtime supports Quota Management API, the application can get the information about the quota using the queryInfo() method of the StorageQuota interface.
navigator.storageQuota.queryInfo("temporary").then(
function(info) {
console.log("Total: " + info.quota + " bytes");
console.log("Used : " + info.usage + " bytes");
console.log("Free : " + (info.quota - info.usage) + " bytes");
}
);The conformant runtime must run the test suites appropriately without any JavaScript error:
All of the conformant runtime must run this test appropriately.
This test downloads a video file as a blob object using XMLHttpRequest. Then the file is stored using Indexed Database API if supported. If not, this test tries to use File API: Directories and System.
If the file is stored successfully, this test tries to get the file as a blob object from the storage, to create a video element, then to play the video.
All of the conformant runtime must run this test appropriately.
This test downloads an image file as a blob object using XMLHttpRequest from the site whose origin is different from this test script.
If the image file is downloaded successfully, it will be shown in this test page.
All of the conformant runtime must run this test appropriately.
This test tries to call the queryInfo() method of the StorageQuota interface specified in Quota Management API. If succeeded, the total size, the free size, and used size will be shown.
All references are normative unless marked "Non-normative".