Bristol Wearable Computing

[ Home | Plans | Meetings | Members | Search | Papers | Links | CyberWear | LocoSoft]


Designing the Situated Computing Server: Engineering or Architectural Approach?

The Situated Computing Server can be designed according to two different approaches:

Architectural Approach

According to this approach the server needs to be able to support situational information of any type, regardless of the incidental opinions of the platform designers about what may be actually useful. The idea is that the wearable computer platform designers cannot be expected to anticipate what kind of situational information may be utilised by the future developers of sensors and situated applications. The jobof the server is to enable a free market for different providers and consumers of situated information. The SitCompServer provides an Interface Definition Language that allows those involved in the development of new sensors, context drivers and situated applications to describe different types of situated information. The SitCompServer is then able to match situational information offers to requests on the basis of type.

The advantage of this approach is that it is general: it is designed to be able to support any future situational dimensions. The disadvantage is that it requires an interface descrition language, making it more challenging to design and may suffer performance penalties for its generality.

It also assumes a world where standardisation of situational dimensions is driven by market forces - if it happens at all. In other words, standards will emerge in an adhoc manner according to what situational information is commonly provided by sensors and requested by situated applications. This form of democracy is not always guaranteed to leave us with the best technology solutions! So be it!

Engineering Approach

In this approach we build in the set of situational dimensions that the server can support. The idea is that one of the jobs of the wearable computer platform designers is to specify in advance all the useful situational dimensions that could be supported by a wearable computer. This approach is more restrictive but also simpler for designers of sensors and situated applications. It may be necessary to add new situational dimensions in the future and in that case it will be necessary to upgrade all wearable platforms to achieve this. This could possibly stiffle innovation in the real world, but perhaps simplicity makes this a price worth paying.

In such a scheme we may also decide to let the SitComp Server prescribe which kinds of situation information are visible to applications and which may be provided by sensors. Again the philosophy is to guide application and sensor designers towards good solutions, but to restrict the choices available to them.

Discussion

It would be unrealistic for this team to try to define all useful situational dimensions. Consider for example, us trying to invent a situational dimension to describe a person's mental state. Not an easy problem, and not something we want to rush out! So, if we proceed with the engineering approach our platform will definitely not be able to support the full set of useful situational dimensions. Is this ok? This approach will still allow us to learn something about how adequate our ad hoc solution will be, and thus give us some feel for whether the approach is tennable in the long run. In contrast, although the architectural approach provides a proof of concept of a general solution, it dismisses the possibility of a simpler engineering solution.

Is there a compromise? One could imagine a solution where we take the architectural approach, but allow a particularly limited number of atomic data types to describe situational dimensions. However, it would still be necessary to allow a rich name space so that when for example a situated application asks for an integer representing the number of companions in a room in doesn't actually get an integer representing the day of the month. Once you have such a rich name space, you have in principle returned to the architectural approach. On the other hand, if you restrict the name space to pre-defined situational dimensions (decided by the SitComp server designers) then you return to the engineering approach. Essentially the situational dimensions have to be decided either by the platform designers or by the platform users; you can't have a bit of both so no genuine compromise is possible on this point. What you can do is design the platform so that new situational dimensions can be incorporated into the platform with the wearer's approval. This is, if you like, the engineering approach, but with special support for SitComp server upgrade. If the server is truly upgradeable then we return to requiring an Interface Description Language and the SitCompServer design returns to the complexity of the architectural approach. All we have done is obscure the source of situational dimension designs by interjecting the user! Mmmm...

Comments welcome!

jbr 25/02/98


unicrest.gif (4191 bytes)

The material displayed is provided 'as is' and is subject to use restrictions.
For problems or questions regarding this web contact Cliff Randell.
Last updated: January 14, 2000.
logoep.gif (1404 bytes)
ęCopyright Hewlett-Packard 1997-2000.