The q·.:launcher registry intends to provide the functionality to bind Apps of a user to arbitrary service requests. In this context, a Service request is simply asking the user to start an App that is able to handle the information provided by the Service request. Service requests can originate from several sources, like Tweets, Text messages or barcodes. The Figure below shows a concept map of the q·.:launcher registry and illustrates the connections between all physical and logical entities.
Concept Map of q·.:launcher Registry
Note that the actual q·.:launcher registry emerges from the interactions between the entities (Bindings, Meta Data, User, Provider, App Store). Like a good sports referee, the q·.:launcher registry is invisible. However, by providing the important features like binding in the background,it acts as bridge between user, provider and App store.
Technically, the q·.:launcher registry consists of two main components: a local registry and a remote registry. The local registry contains a subset of the registry entries of the remote registry and can be regarded as cache of the remote registry. As soon as the user receives a Service request, q·.:launcher looks up the local registry of the user for an app that can be bound to the Service request. If a binding can be found, the registry asks the user to execute the corresponding App. If no binding can be found, the remote registry is queried and the several binding options are offered to the user. It is very important not to overload the user with options. Therefore, the registry must provide an intelligent filtering mechanism that gives the user only a small set of Apps to choose from.
The q·.:launcher registry data model contains three main categories. First of all, it offers basic information about the App. This is – among other meta information like price – the name of the App, the name of the App provider/developer and contact information. Second of all, the q·.:launcher registry provides information where to get the App, i.e., links App Stores. And finally, binding information is also provided. Binding information is crucial for the actual invocation of the App, after a Service request was received by the user. We foresee three different types of requests: text messages, Tweets and messages that are encoded in barcodes.
These three request types map to three different scenarios for the use of the q·.:launcher registry. In the first scenario, the q·.:launcher registry is integrated with barcode scanner Apps. Here, after a barcode is scanned, the registry looks up Apps that can handle the data of the barcode. For example, if a barcode contains contact information like vcards, mecards or q·.:cards, the corresponding App should be started and the data should be passed to the App. Likewise, if url schemata like mailto:, sms: or geo: are present, then Apps like mail, text messaging or map applications should be executed. The second and third scenario are related from a technical perspective, but differ conceptually. In scenario two, text messages are scanned for occurrences of Service requests which are encoded as Tweetflows. After a Tweetflow has been identified, the registry is queried for bindings and the data from the text message is passed to the App. This requires additional considerations, like the handling of text message and the registration of dedicated URL schemata. This is out of the scope of this post, but we will discuss this details in one of our next posts. And finally, the third scenario considers the integration of the registry into Twitter Apps. While similar from a technical perspective, the main difference to text messages is the scope of Tweets. Tweets are sent to hundreds of followers whereas text messages are typically sent to single individuals. Users receive more Tweets than text messages and thus we need to treat Service request Tweets differently than text message, due to the amount of Tweets. We are investigating filter techniques that put Tweets that contain Service requests into queues of certain length, preventing the user from being overloaded by Service requests.
your ikangai science team