The Layers of the diretto Platform

The diretto platform is not a single application. It is rather a set of modular components both in terms of usage and of general project architecture. This blog entry describes the different layers and the underlying ideas of the system.

The common ground is an elaborated conception, what distributed reporting should be for the diretto platform. The key entity is a document, that is a testimony of an event. A document possess a geo-spatial and temporal source of origin. While documents are abstract entities, there are always at least one attachment appended to it. Further attachments allow enhanced or processed variants of the original piece. Users can apply tags and comments to a document, propose updated time/place origins and vote on all of these items. Key value pairs provide additional tags beneficial for machines and links allow to connect causally related documents.
While this was a rather generic description, here is an example: Alice is eye-witness of an event an takes a photo (document) with her smartphone. She uploads the raw image (attachment), and appends the time and position. Unfortunately, Alice does not have GPS enabled, so the position is inaccurate. Bob is not on-site but accesses the platform via browser. He sees the images and recognizes the exact position. He then proposes an improved position and appends some useful tags. He downloads the image and improves the contrast. He then uploads the outcame as an additional attachment. Other examples for documents are videos, audio recordings, text messages, sensor reports etc.

To make this conception computationally comprehensible, it is described in form of a language-agnostic API. In detail, we have chosen a RESTful approach, based on HTTP. Thus our API is a set of (connected) resources and valid operations on these resources. Different concerns are separated by different APIs. So there is for instance an API that handles the upload, download and storage of raw documents that have been submitted. But handling comments, votes etc. is handled by another API, and so on. This not just modularizes the API, it also allows you to use only subsets of the API, depending on your use case.

Basically, you could start to implement components for the diretto platform by implementing the two sides of the API – the service providers (servers), and the service consumers (clients). However, we offer a middleware that already provides the platform internals, based on the APIs. More precisely, we offer a backend service implementation that represents a service provider. On client side, we offer ready-to-use client libraries so you don’t have to deal with low-level communications.

So relying on our middleware allows you to build your specific reporting application on top of the platform. Whether you are bird-watching or you are going to provide live-coverge of a sports event – you don’t have to start from scratch. Instead, you can select from the diretto platform the parts of the toolkit that you actually need and directly start to develope it.

Tags: architecture, layers, project