What is a DMApp?
Central to the work and the prototypes of 2-IMMERSE is the creation of DMApps. MARK LOMAS from BBC R&D offers an explanation of how the project understands them.
What is a DMApp?
At first glance, the word ‘DMApp’ looks simple enough, but this crafty little concept had us scratching our heads for quite some time before we could agree on a definition. Initially, we couldn’t even agree on an abbreviation – for some people it was “D.M.App”, whilst others preferred “D.Mapp”. It stands for ‘Distributed Media Application’, an application that orchestrates media playback across a number of devices at the same time, but DMApps turned out to have many layers of complexity that took us a while to get to grips with.
We originally viewed a DMApp as a TV broadcast that was capable of displaying extra interactive content on connected devices, governed by a timeline document and timeline service, but this was an incomplete picture as we soon discovered during the development of the Theatre-in-Home use case. We found that application logic, state management, cloud services and statically hosted assets were essential DMApp ingredients as well.
Applications and Programmes
We moved a step closer to a definition when we started to think of the broadcaster’s timeline as an episode playing back through a reusable DMApp. It seems obvious in hindsight – a single reusable theatre DMApp that can show many different performances!
So, are timelines just programmes? Well, not exactly. They are actually more like concurrent finite state machines driven by external events. They are responsible for managing the life-time of application components within the distributed system. Therefore, Timelines represent flexible data-driven application logic that runs in the cloud supplementing the static application logic running elsewhere.
Whilst grappling with timelines, we were also struggling with where to put “glue code” – the application logic that responds to user interactions and updates the app’s state. We had a video chat feature that was composed of three different visual components that interacted with each other, but they were distributed across several devices. It wasn’t clear where the glue code for this feature should be hosted. Was there a preferential device? Should it run as a microservice in the cloud?
The answer turned out to be “run it anywhere you like!” and the question we should have been worrying about was “How do we synchronise data between logic components running on many devices?“.
You see, a DMApp is very hard to pin down because it’s smeared out across multiple services and end-user devices. It’s also smeared out temporally, having a lifespan that’s independent of any single device connected to the experience. That is to say the life time of a DMApp is decoupled from the actual ‘app’ running on your smartphone or TV. This is very unlike a conventional single device app. So where does a DMApp start and end? and indeed when?
To make sense of this, we stratified the DMApp into a set of layers with independent life spans. The lifetime of some application layers is bound by the programme duration, the lifetime of components is governed by the timeline, whilst other layers have independent durations. We introduced new layers responsible for launching and discovering programmes whilst also adding a layer to bootstrap code from the CDN. The full stack looks like this:
A broadcaster can commission the development of a set of reusable DMApp components for the season or programme genre, together with a timeline template that serves as a basis for formulaic episodes. Each individual episode requires a unique timeline document that references media specific to that episode. Playback of the episode would be initiated via the DMApp launcher layer running in a web browser, on a companion device or a TV.
So, what is a DMApp again? It’s
an application that runs independently in the cloud and extends itself onto client devices that are running a reusable layered client application.
At least that’s our best guess at the moment!