Context Toolkit: Tutorial: Upcoming Features
Here, I will list the set of features I would like to add to the context
toolkit. Again, this list is not complete, but just contains what I could
think of off the top of my head. Feel free to let me know what features
you would like to see and I'll do my best to get them added. Conversely,
if you add any interesting features, please let me know and I'll add them
to my system, making them available for other users.
In this section, I will describe the basic features that I would like to
add to the context toolkit.
In order for two components to communicate with each other, the initiator
has to know the hostname, port, and id of the component it wants to communicate
with. In reality, a component should not need to know this information.
It should only need to know what how to describe the desired component.
For example, an application wanting to know when anyone enters a room should
be able to automatically find any components (widgets/servers in this case)
that can provide this information. Resource discovery will help support
Once resource discovery is available, a visualization of the various running
components (widgets, servers, interpreters, and applications) can be developed.
This would show which components are communicating with other components,
either sporadically (poll, request for information) or continuously (subscription)
and the data that is being passed between components. This should help
with debugging a complex system.
The Conditions object is a collection
of individual Condition objects.This collection is interpreted as an AND'ed
set of conditions. In other words, when a component subscribes to a widget
and sets a list of conditions, all of the conditions must be true in order
for data to be returned to the component. I would like to extend this to
support NOTs and ORs, to permit greater flexibility.
In this section, I will describe advanced features that I would like to
add to the context toolkit.
Currently, the context toolkit assumes that all the context collected is
100% accurate. This is not always the case (in fact, this is quite infrequent),
but is a common simplifying assumption made. I would like to add support
for dealing with ambiguous context. This includes:
Jen Mankoff (a fellow PhD student) and I have started work on the last
of these three support mechanisms. For more information on this, look at
Jen's research on Errata.
passing the accuracy of every piece of context with the context data
fusing context captured by multiple sensors, when the sensor data agrees
and when it doesn't agree
allowing human users to indicate what the correct value of the ambiguous
context should be.
With the ability to easily sense and pass context information around, there
is an increased need to limit access to the information that we consider
personal or private. David Nguyen (a fellow PhD student) is working on
a system that will help people manage, distribute and sense the flow of
personal information in a ubiquitous computing environment, in a project
& Mirrors.We have added the ability to send an authentication id
with a request for context history. Obviously David's work goes far beyond
this simple addition and as he makes progress, I will update the context
Back to the Table
Forward to the References
Last Modified: Feburary 11, 2000
Comments to: email@example.com