Original Publication Date: 2003-Nov-19
Included in the Prior Art Database: 2003-Nov-19
In today's world, plugging together devices from different makers still involves planning , installation and human intervention. In a network where devices might be plugged in, plugged out or interchanged, we would like to minimize the dependencies between them, and therefore minimize their knowledge about one another.
In order to fit together devices which were designed independently we sometimes need to make adjustment in them. We also want to make adjustments to allow devices to support needs which were unforseen at the time they were made. One way to enable this is to allow to "push code" into devices.
Example 1: many devices were not built with the special needs of jewish religous people in mind, and can not be programmed to activate themselves automatically on saturdays and holidays. If we could "push code" to the air-conditioner which would extend it with such a feature,we could solve this problem.
Example 2: Suppose a device connected with low bandwidth implements a radioactive random number generator. This device would like to push code into its users, so that most requests would use a pseudo-random generator which will run on the user, and every 100 requests the device will supply this generator with a new seed.
Example 3: A cellular phone can be looked as both a client and a service provider. We would like the phone, when arriving to a new network , or when plugged in the car, to announce "I'm here , I've got a microphone , A screen with such and such properties , A speaker , A keypad": In this way we look at the phone as a service provider.(It misht also provide other services regarding its function as a phone). Yet sometimes , the service that we need from the phone is to be able to display menus and fill out forms. For example: suppose my bank wants to send me a message that my balance is high and give me a menu of options where to invest it. The code to show menus and fill forms only needs the Screen and Keypad services , but if we can't upload it to the phone, the feedback to the user might be too slow to be acceptable. Of course, if the phone manufacturers had foresight, they could have come up with a standard MenuAndFormsDisplayer interface , and implemented it in the phones. What we want is to be able to extend these devices with features the manufacturer didn't think of, or features for which there is no standard. Note that the "no standards" problem is similar to the preceeding problem: we have a phone which implements the NokiaMenuAndFormsDisplayer and we want to extend it to implement the HtmlMenuAndFormsDisplayer or the CellcomMenuAndFormsDisplayer.
We would like a solution that would enable in example 1 , a "jewish remote control" to connect to a regular air conditioner , and in example 2 , enable a user to connect to the radioactive generator , without being aware that a large part of the proccesing is done locally. In example 3 we would like all diverse phones, which were built without thinking of the need for publishing the menu and forms interface, to be able to work uniformly in a network which decided to provide this feature.
We would like the makers of such devices to be able to focus on the functionality they provide, and still make sure that these devices will be able to support unforseen need , and...