Context Toolkit: Tutorial: Problems and Bugs

Here, I will list the known problems and/or bugs with the context toolkit. This is obviously not a complete list - I only listed the ones I could remember off of the top of my head. If you find (I should probably say when you find) any additional problems/bugs, please let me know. I will publish a fix as soon as I can.

Severe Bugs

Inconsistency in AttributeNameValue
When an AttributeNameValue is created, the "value" field is an Object, and can be a Long, Short, Integer, String, Float, or Double. However, when the AttributeNameValue is sent to another component (converted to a DataObject - a string - and then converted back to an AttributeNameValue), the "value" field is set to
a String. This isn't a real problem because the "type" field allows you to figure out what object type the "value" field should be, but it can be confusing for a programmer. The same may be true for the Condition object.

Problems

Duplicate Attributes
Because of the specific way in which we implemented our data storage mechanism for storing context information in widgets and servers, we can not support the use of duplicate attributes. Here's an example to illustrate this problem:

The context being captured is a group of books. In our default XML representation, it looks like:

    <BOOKS>                Attributes books = new Attributes();
      <BOOK>...</BOOK>     books.addAttribute("book");
      <BOOK>...</BOOK>     books.addAttribute("book");
      ...                  ...
    </BOOKS>               Attributes atts = new Attributes("Books", books, Attribute.STRUCT);

The default storage mechanism we use does not allow the use duplicated context attributes. Instead, the following must be used:

    <BOOKS>                Attributes books = new Attributes();
      <BOOK1>...</BOOK1>   books.addAttribute("book1");
      <BOOK2>...</BOOK2>   books.addAttribute("book2");
      ...                  ...
    </BOOKS>               Attributes atts = new Attributes("Books", books, Attribute.STRUCT);

The problem results from our automatic conversion of a widget's attributes to a table creation in a database.

Server Problem
By default, a server caches the last known value for each context types it has access to. When a new value for a given context type is received (usually via a subscription), it replaces the previous value. In many cases, this is adequate behavior. For example, a server that represents a person X keeps track of that X's location. When X changes location, the old cached location is replaced with the new location. However, there are known cases where this behavior is not acceptable. For example, a server may keep track of the people who are around X. When someone new enters the room that X is in, the current behavior is to replace the old person in the room with the new person. Instead, what should happen, is the new person should be added to a list.
Component Parameters
The storage mechanism is pluggable. This means that the default storage mechansim can be replaced by a user-provided one. The default mechanism uses some important variables: machine that stores the context data, account and password to access that machine, etc. Right now, these variables have to be set explicitly, and can not be input on the command line at run time. Instead, the storage class has to be edited and recompiled. This is a small problem, and should be easy to fix.

UPDATE (02/29/00): Rather than have to modify every widget everytime we need to add a new command line parameter, we're going to allow widgets (and servers and interpreters) to use configuration files that will contain all the necessary start-up information. By using a configuration file, only the class that parses the configuration file and the Widget class will need to be updated whenever new parameters are added. Hopefully this capability will be added soon.

Global Time Clock
Each piece of context that is sent between components has an associated timestamp. Because components are running on different machines and each machine has its own clock, it may be difficult to compare timestamps of context originating on different machines. We have implemented a solution to this using the Network Time Protocol, but I haven't incorporated it into my version control system.

UPDATE (02/24/00): The latest update contains a fix for this problem as outlined above.

Server vs. Aggregator
I want to change the name of the context.arch.server package and all the classes in it to use the word Aggregator rather than Server. While this should be a simple fix, I can't figure out how to make this change with my version control system, so I don't lose all the recorded changes to the Server.java file. I'm using CVS, so if anyone has experience doing this in CVS, please let me know. In the meantime, whereever you read Server, think Aggregator. The reason for this is that the word "server" is over-used and can mean too many different things. In particular, I've had people get confused, thinking that we were providing servers as in the "client-server" paradigm. That's not the case - we have a peer-to-peer model. Aggregator is a better word to describe what we have been calling a Server.
Thread Creation
In BaseObject, whenever a new incoming request is received, a new thread is created. The thread dies after servicing the request. The time to create a thread and garbage collect the dead thread could be saved if we used a thread pool. This should improve performance for a component that is receiving a lot of incoming communications.

Back to the Table of Contents.

Forward to the Upcoming Features section.

Context Toolkit Home
Last Modified: March 15, 2000
Comments to: anind@cc.gatech.edu