Application Query API
Note: This page is under construction and serves primarily as a discussion forum.
The application query API defines how applications tell the Ubitrack framework about the spatial relationships they are interested in.
We decided upon modeling this API as a Need of a DWARF application. Thus, the API consists of a collection of a
, the semantic of each will be specified below. However, mapping to other access methods should be easy.
of a need specifying a query for absolute 6 DOF position and orientation spatial relationships to the Ubitrack layer must be
of the need specifies the access method. The following dimensions are proposed:
- pull (the application pulls data from Ubitrack) vs. push mechanism
- synchronous vs. asynchronous call semantics
The following DWARF connectors have to be specified for the resulting four combinations:
| Method || Connector Type || Comments |
| asynchronous push || |
| This is the most common method. The application specifies its needs and provides an event sink for CORBA notification events to be sent by the Ubitrack system whenever data is available. |
| asynchronous pull || |
| Once the Ubitrack layer has set up a data flow structure, it offers the application a CORBA object having a method for getting positional data. A call to the method returns immediately. If data is available, the Ubitrack layer sends an event to the application. |
| synchronous pull || |
| Once the Ubitrack layer has set up a data flow structure, it offers the application a CORBA object having a method for getting positional data. A call to the method returns only after data is available. |
- We could the
PullConsumer connector type for asynchronous pull communication. This is a (so far totally undocumented) connector that retrieves the last event from a notification channel. See the
TestStringPuller service for an example. I think this can be configured to return immediately if no data is available, or to block. That would eliminate the clumsy sending of a request before retrieving an event... -- AsaMacWilliams
- However, I do not see immediately if aking the last event out of a notification channel satisfies all possible requests. What happens if the time offset is different than that of events stored in the notification channel? -- MartinWagner - 15 Oct 2004
- The push model is always asynchronous (from the Ubitrack layer's point of view), thus it doesn't make sense to distinguish between sync/async push mechanisms. -- ThomasPintaric?
- You're right. I removed it. -- MartinWagner - 15 Oct 2004
Attributes are unsorted name-value pairs of strings. Currently, there exist no possibilities to enforce strict typing on them. Thus, special care has to be taken that both users and developers of the Ubitrack system adhere to the following common attributes. To minimize inference with other attributes used to describe DWARF services and/or needs, we prefix every attribute's name with
| Attribute Name || Value Type || Semantics |
| Float || The desired update rate in 1/s. No guarantee is given by the Ubitrack layer to reach exactly that value, it is just a best effort method. If this attribute is zero, only a single data item is sent, which might be useful for static relations. |
| String || The source object ID. This object's coordinate system is the base of all positional information returned by the Ubitrack layer. Note that currently, the ID has to be known by the application, however, we might add wildcards evaluated by some spatial indexing service. |
| String || The target object ID. Wildcards see above. |
| (Long,Long) || Based on the time the query is released to the Ubitrack layer, this value gives the offset to the desired time at which the spatial relation should be evaluated. Positive values indicate future points in time (thus requiring prediction components), negative values past points in time. If |
UTUpdateRate is not zero, the given offset is constantly applied to the initial time plus multiples of the update interval. A pair of seconds and milliseconds.
| String || This value gives a specification of the evaluation function to be applied. Whilst it will be a highly complex XML-based description in the near future, we agreed for the time being to offer a limited choice of several specific non-parameterized error functions to be listed here later. |
- I edited all of the attribute names so that they do not contain underscores. This is silly, but OpenSLP crashes if you use attribute names with underscores. Perhaps we should use another prefix notation. -- AsaMacWilliams
- At our discussions at the Ubitrack Workshop several other potential attributes have been mentioned, but I do not understand their meaning right now.
Perhaps somebody could comment on them:
- QoS Request
- Resource Discovery
- Spatial Granularity
- Query preparation (General idea: "assemble" a query ahead of time and "activate" it when necessary). How should we model this?