The basic idea behind Splice  is that a process which consumes certain data need not know which process produces it. In fact, there may be several producers. The consumer simply registers its interest by subscribing to a certain data sort. Next it will be able to read produced data items of this sort, where it can use keys and queries to filter the data stream on certain aspects (e.g. in an air traffic management system, on flight number or distance to the airport). Similarly, the producers need not know the consumers of their data.
In the rest of this section we consider several examples of simple programs using read and write primitives. The intended meaning of these primitives will vary per example, but the basic intention is that writes the value of to the dataspace(s) and asks the dataspace a query and assigns the answer of the dataspace to its variable .
Typical for the applications built with Splice is that it is often not needed to ensure that all data will be consumed or that it will be consumed in the order it is produced, since there is usually a continuous stream of data available from the sensor. Moreover, there are often no strong consistency requirements on processes that consume the same data.
Hence, Splice provides a simple but powerful coordination scheme that requires little overhead. Nothing is guaranteed about the speed or order at which data items of producers become available for consumers.
For instance, in the program
But if, for instance, ordered messages are needed, sequence numbers can be included in the data and the reader might read with a query on the next sequence number. It is also possible (and often done in practice) to include a time-stamp in the data sort and to express in the query that the data has a recent time-stamp.
Given this basic idea, there are a large number of possible variations, especially concerning the syntax and the semantics of the read operations. We list a number of questions: