Universal information appliance with parser6292186Abstract A universal information appliance (UIA) such as can be embodied by a personal digital assistant (PDA) can receive an application written in a new "MoDAL" language, parse the application to divide it into binary-formatted GUI elements, and then dynamically render a GUI interface on the display of the UIA based on the GUI elements parsed out of the application. The user can further modify the GUI and save it. With this combination, a GUI can be easily and dynamically tailored for a wide range of user needs, including the needs of handicapped users. The UIA communicates data in an onboard data cache with globally shared, associatively addressed memory spaces such as "TSpaces". Claims We claim: Description BACKGROUND OF THE INVENTION
<APPLICATION name = Hello>
<FORM name="MainForm" label="Hello"
x="160" y="160" height="160" width="160">
<TEXTFIELD name="TFhello" x="80"
y="130" height="12" width="80"
maxchars="30" multiline="true">
</TEXTFIELD>
<BUTTON name="BHello" label="Say hi" x="120" y="145">
<ACTION>
<SET name="TFhello">
<STRING>"Hello World"</STRING>
</SET>
</ACTION>
</BUTTON>
</FORM>
</APPLICATION>
With the above example in mind, MoDAL syntax is set forth as follows. The name of the application, and its "owner", are set forth in the first line above. In general, the format for setting forth the application name and owner is <APPLICATION name="string" owner="string2">; </APPLICATION>. A "form" is the top of the MoDAL descriptions. All other statements are inside this one. The name field in the first exemplary line above is a required attribute, and it is used only for identification purposes. The owner field is optional and it will default to "MoDAL". In the fields above, the types of data in the name and owner fields are indicated as being character strings. Moving to the next line in Example (1), an example "form" element is as follows: <FORM name="string" label="string2" x="string3" y="string4" height="string5" width="string6" [savebehind="true".linevert split."false"] [menu="string7"] [MoDAL="true".linevert split."false"] [usable="true".linevert split."false"] [help="help_name"]> It is to be understood that other elements, such as GUI elements, e.g., fields, buttons, etc., should be defined inside a Form. The syntax </FORM> defines a form, which is needed to declare any other UI element. Required attributes fields in forms are as follows (using entries in the example above): name: id used to invoke the form, used in <FORMGOTO name="formname"></FORMGOTO>label: title of the form; x: x coordinate of the top left corner of the form, x="0"; y: y coordinate of the top left coordinate of the form, y="0"; height: height in pixels, height="160"; and width: width in pixels, width="160". In contrast, optional attributes that can be part of a form are as follows: savebehind: turn on, off the savebehind bit, default is false; menu: id of the menu element to be associated with this form, default is no menu, menu="MainMenu"; MoDAL: turn on, off the MoDAL bit, default is false; usable: turn on, off the usable bit, default is true; help: id of the help element associated with this form, help="HelpString"; As shown in example (1) above, a TextField can also be provided having the following syntax: <TEXTFIELD name="string1" x="Xvalue" y="Yvalue" height="Hvalue" width="Wvalue" maxchars="value" [SingleLine="true".linevert split."false"] [usable="true".linevert split."false"]; [editable="true".linevert split."false"] [underline="true".linevert split."false"] [autoshift="true".linevert split."false"] [ScrollBar="true".linevert split."false"] [numeric="true".linevert split."false"]> [<ACTION> </ACTION>] </TEXTFIELD> Actions may be defined to occur when a user selects the text field. Required attributes of a textfield are as follows: name: id of the text field; x,y,height,width: coordinates and dimensions of the field in pixels; and maxchars: maximum number of chars the field can contain. Optional attributes of the "text field" include: singleline: field can only have 1 line of text, no carriage return is accepted, default is false; usable: field is displayed on the form if set to true, default is true; editable: if true user can enter values, if false values are set only from the application, default is true; underline: true or false, displays underlined characters, default is false; autoshift: set autoshift, true or false, default is false; scrollbar: field has a vertical scrollbar, true or false, default is false; and numeric: field can contain only numeric characters, true or false , default is false. Further, example (1) above shows that a GUI button element can be defined in a form, and the syntax to do so is as follows: <BUTTON name="buttonid" label="text" x="xvalues" y="yvalue"; [usable="true".linevert split."false"]> [<ACTION> </ACTION>] </BUTTON> It is to be understood that the "Actions" listed in the action fields are associated with the button and are triggered when the user clicks the button. Required attributes of the "button" are as follows: name: id of the button; x,y,height,width: coordinates and dimensions of the button in pixels; and label: text to be shown on the button. Optional button attributes include "usable", which indicates whether the button is displayed on the form (if set to true), with the default being true. In addition to or in lieu of a button, a GUI checkbox can be defined in a form, and the syntax to do so is as follows: <CHECKBOX name="CB_name" label="text" x="int" y="int" selected="false" [usable="true".linevert split."false"]> [<action> </action>] </CHECKBOX> This syntax defines a checkbox in a form and lists actions that will be invoked when the user click on the checkbox. Width and height attributes are not used, it being understood that they are set automatically depending on the number of characters in label. Required attributes of the checkbox definition are: name: id of the checkbox; x,y: coordinates of the checkbox in pixels; label: text to be shown on the checkbox; and SELECTED: true or false, with "true" displaying the checkbox as selected. Optional attributes of a checkbox include "usable", which indicates whether the checkbox is displayed on the form (if set to true), with the default being true. A "CheckBoxGroup" can also be defined on a form with the following syntax: <CHECKBOXGROUP name="group_name"> [<checkbox>..] </CHECKBOXGROUP> This feature of the MoDAL language is used to group one or more check boxes together, and only one checkbox will be checked at a time inside the group. A Label element can also be defined in a form using this syntax to add static text to a Form: <LABEL name="label_name" label="text in the label" x="int" y="int"></LABEL> The height and width of a label are calculated based on the number of characters in the label. Furthermore, using MoDAL syntax a List can be defined in a form thusly: <LIST name="list_name" x="int y="int" height="int" width="int" rows="int" [visibleRows="int"] [usable="true".linevert split."false"]> [<ACTION>MoDAL_actions </ACTION>] </LIST> Actions set forth in the definition of a "list" are executed when the user selects a row in the list. The attribute selected indicates the row number of the user selection, with rows being numbered starting from the top and being zero-based. Optional attributes of a list are: visibleRows: number of rows in the list to display, defaults to the value of rows; and usable: true or false, defaults to true, it should be false when declared inside a POPUP menu or list as described more fully below. With the above in mind, a POPUP menu or list element is defined in a form as follows: <POPUP name="popup name" label="popup_label" x="value" y="value" [usable="true".linevert split."false"]> [<LIST . . . >MoDAL_actions</LIST>] </POPUP> A POPUP element may contain only one LIST declaration. The height and width of a POPUP list are calculated based on the number of characters in the label attribute. Lists that are declared inside a POPUP element should have the usable attribute set to "false". MoDAL actions inside this List may not be required because the preferred Palm operating system (OS) automatically sets the POPUP label to the list selection. A menu UI element can be defined thusly: <MENU name="menuName"> <SUBMENU label="MenuLabel"> [<SEPARATOR></SEPARATOR>] <ITEM label="ItemLabel"> [<ACTION>MoDAL_actions</ACTION>] </ITEM> [<SEPARATOR></SEPARATOR>] [<ITEM>. . . [<SEPARATOR></SEPARATOR>]. . . ] [<KEYBOARD></KEYBOARD>] [<GRAFFITI></GRAFFITI>] </SUBMENU> [<SUBMENU>. . . ] </MENU> The above syntax defines a menu element inside an application. This syntax must be defined outside a form, before the form it will use it. Menus are associated with a form by setting the menu attribute of the form to the name of the menu. In accordance with the present invention and as indicated in the syntax above, menus contain one or more sub menus, and sub menus contain one or more "items". Items may contain actions that are associated with the menu for invoking the actions when a user clicks on the menu. Moreover, a "separator" draws a horizontal line between menu items. Separators may be declared anywhere in a sub menu, outside "items" declarations. The "keyboard" syntax, on the other hand, brings up the keyboard reference dialog, the focus of which should be on a TEXTFIELD. Otherwise, the Palm OS will not display the keyboard. Completing the explanation of the menu syntax, "graffiti" invokes the graffiti reference dialog, if any. Returning to what can be defined inside a form, a "help" string in a form can be defined as follows: <HELP name="helpName" label="help text"></HELP> The help string is associated with the form element by setting the help attribute to the "help" name attribute, i.e.,: help=help_string. Additionally, a table can be defined inside a form thusly: <TABLE name="table_name" x="int y="int" height="int" width="int" rows="int" cols=int [visibleRows="int"] [usable="true".linevert split."false"]> [<ACTION>MoDAL_actions </ACTION>] </TABLE> In the above syntax, the row height and column width is the dimension of the table divided by the number of columns or rows. As disclosed previously, in addition to UI elements, action elements can be defined as shown in example (1), and the preferred syntax for the first action element (reading data from the local cache 48) is as follows: DBREAD (database read): <DBREAD name="dbName"> <RECORD> <GET . . . >.linevert split.MoDALTYPE </RECORD> <FIELD> <SET name="element_name" attr="atr_name"></SET> </FIELD> [<!--other fields-->] </DBREAD> The DBREAD action reads a record from the local data cache 48. The value inside the <RECORD> element indicates what numerical record to read. It must be an integer, or the attribute of an <ELEMENT> that stores and integer. The <FIELD> elements specify where to store the retrieved information. One or more fields may be retrieved on one DBREAD operation. As set forth more fully below, various types of MoDAL values such as integers, floating point decimals, strings, and characters for the various variables that are called for can also be defined. As an example, assume that a MoDAL application includes a form and a list that will be updated after retrieving data from the local data cache 48, with a button being used to read the data cache 28 and update the list with the retrieved information. The syntax to invoke this is:
<APPLICATION name="DB read example">
<FORM name="exForm" x="1" y="1" height="160" width="160">
<LIST name="exList" x="10" y="25" height="80"
width="80" rows="5"></LIST>
<BUTTON name="update" x="60" y="20" label="update">
<ACTION>
<DBREAD name="data_base_name">
<RECORD><INT>"1"</INT></RECORD>
<FIELD> <SET name="exList"
row="1"></SET> </FIELD>
</DBREAD>
</ACTION>
</BUTTON>
</FORM>
</APPLICATION>
The DBWRITE (database write) action element writes data to the local cache 48 using the following syntax: <DBWRITE name="dbName"> <RECORD> <GET . . . >.linevert split.MoDALTYPE </RECORD> <FIELD> <GET name="element_name"></GET> </FIELD> [<!--other fields-->] </DBWRITE> The value inside the <RECORD> element indicates what numerical record to write. It must be an integer, or the attribute of an <ELEMENT> that stores an integer. The <FIELD> elements specify where to get the information to be written. One or more Fields may be retrieved on one DBWRITE. When reading the information with a DBREAD the type of the fields should match the ones used during a DBWRITE. As an example, assume that a MoDAL application intends to write a text field to the local cache 48 using a button. The following syntax would be used:
<APPLICATION name="DB write example">
<FORM name="exForm" x="1" y="1" height="160" width="160">
<TEXTFIELD name="exfield" x="10" y="25" height="20"
maxchars="80" ></TEXTFIELD>
<BUTTON name=exButton x="60" y="20" label="save">
<ACTION>
<DBWRITE name="data_base_name">
<RECORD><INT>1</INT></RECORD>
<FIELD> <GET name="exfield"></GET> </FIELD>
</DBWRITE>
</ACTION>
</BUTTON>
</FORM>
</APPLICATION>
It is to be understood that the user can write data in the text field in, e.g., record 1 of the data base "data_base_name". In addition, DBDELETE can be used to delete data in the cache 48 using the following syntax: <DBDELETE name=dbName> <RECORD> <GET name=element_name attr="attr_name"> </RECORD> </DBDELETE> The value inside the <RECORD> element indicates what numerical record to delete. It must be an integer, or the attribute of an <ELEMENT> that stores an integer. As discussed previously, the UIA 12 can transfer data not only to the local cache 48, but to a network data storage such as TSpaces 28. To this end, a TQUERY action can be defined using the following syntax to read a tuple from the specified space in the Tspaces 28: <TQUERY name="space_Name"> <FIELD> <SET name="element_name" attr="atr_name"></SET> </FIELD> [<!--other fields-->] </TQUERY> The <FIELD> elements specify where to store the retrieved information. The type of the field is obtained from the type of the attribute of the element where the value will be stored, and the type for all GUI elements is <STRING> except for <CHECKBOX>, in which case it is an <INT> (integer). "Set" and "get" actions are discussed further below. Further, "fields" may have a defined type and value, for example: <FIELD> <STRING>"NEW"</STRING> </FIELD> The previous lines specify a Field that contains a string and the value should be "NEW". One or more Fields may be retrieved on one TQUERY. As an example, assume that it is wished to update a list after retrieving data from TSpaces using a button to read the data from the TSpaces and update the list with the retrieved information. The following syntax would be used:
<APPLICATION name="Tuple Query example">
<FORM name="exForm" x="1" y="1" height="160" width="160">
<LIST name="exList" x="10" y="25" height="80"
width="80" rows=5></LIST>
<BUTTON name="update" x="60" y="20" label="update">
<ACTION>
<TQUERY name="Tspace_name">
<FIELD> <SET name="exlist" row="1"> </FIELD>
</TQUERY>
<!-- this TQUERY should result in a query for a
Tuple from TSpaces that contains a string -->
</ACTION>
</BUTTON>
</FORM>
</APPLICATION>
A "TSEND" action can be used to send data to the TSpaces proxy 26 and thence to TSpaces 28 using the following syntax: <TSEND name="space_Name"> <FIELD> <GET name="element_name" attr="atr_name"></GET> </FIELD> [<!--other fields-->] </TSEND> The <FIELD> elements specify where to get the information to be sent. Elements contained in a FIELD definition in a TSEND include: GET, DATE, TIME, STRING, INT, FLOAT, CHAR One or more TSend fields may be used. As an example, assume a text field in a form is to be sent to TSpaces using a button to write the information to TSpaces. The following syntax is used:
<APPLICATION name="TSend example">
<FORM name="exform" x="1" y="1" height="160"
width="160">
<TEXTFIELD name="exfield" x="10" y="25" height="20"
maxchars="80" ></TEXTFIELD>
<!- the user can write data in the text field, this will be
written in record 1 of the TSpace
"TSpace_name" ->
<BUTTON name=exButton x="60" y="20" label="save">
<ACTION>
<TSEND name="TSpace_name">
<FIELD> <GET
name="exfield"></GET> </FIELD>
</TSEND>
</ACTION>
</BUTTON>
</FORM>
</APPLICATION>
As alluded to above, a "FORMGOTO" action is provided for invoking a name. The syntax associated with this action is: <FORMGOTO> <GET name="element_name" attr="atr_name"></GET> </FORMGOTO> Here, the element name is the name of the Form to display and is associated with an <ACTION> element. A <STRING> element may be defined as the form name. In some of the above examples, "set" and "get" actions are used. The "set" action sets the attribute of an element to the type value specified as follows: <SET name="element_name" [row="int" [col="int"]]> [[MoDAL type].linevert split.[<GET . . . >]] </SET> The value is optional, and is not used when a "set" action is within a DBREAD or TQUERY action, because the value used under those circumstances will be the one retrieved from the local data base or from TSpaces. "Row" is used if accessing a list or table element, and "Col" is used only if accessing a table. Also, a special value ("selected") can be specified to get the user selection on either "Row" or "Col". "MoDAL type" defines the type of data as described further below. The "set" action has a scope wherein it can be used to set values in <ELEMENT ..> fields outside the form where the "set" action is contained, and it can also set values in UI elements in the same form where the "set" action is contained. The elements that can have values set include: TEXTFIELD (set to a STRING); LIST specify ROW (set to a STRING); TABLE specify ROW and COL (set to a STRING); CHECKBOX (set to an int, char or float). A 0 value will be not checked, and anything else is checked; and ELEMENT (set to the type used to define the ELEMENT). A "get" action is provided to retrieve the attribute value of an element as follows: <GET name="element_name" [row="int".linevert split."SELECTED" [col="int".linevert split."SELECTED"]]></GET> The "get" action is used within DBWRITE, TSEND, or ACTION elements. "Row" is used when getting a value from a list or a table, and "Col" is only used when getting a value from a table. "SELECTED" can be specified to get the current selection, it being understood that "SELECTED" is used only if an ACTION is contained in a LIST or TABLE. Using "SELECTED" from outside a LIST or TABLE will invalidate the GET action, resulting in a NULL value. The "get" action can obtain values from <ELEMENT ..> fields outside the FORM where the GET action is contained, and it can also obtain values from UI elements in the same form where the GET action is contained. A GET action obtains values from the following elements: TEXTFIELD (gets a STRING); LIST specify ROW, (gets a STRING); TABLE specify ROW and COL, (gets a STRING); CHECKBOX gets an int. A 0 value will be not checked, and anything else is checked; and <ELEMENT (get the type defined with the ELEMENT). A "date" action of the syntax <DATE></DATE> returns a STRING element with the current date in the UIA 12 clock. Similarly, a "time" action having the syntax <TIME></TIME> returns a STRING element with the current time in the UIA 12 clock. In contrast, an "application stop", or APPSTOP action element having the syntax <APPSTOP> <GET name="element_name" attr="atr_name"></GET> </APPSTOP> stops the processing of events for a MoDAL application. The APPSTOP action element draws a form listing other available MoDAL applications to allow the user to run a different MoDAL application. Thus, this keyword will signal the MoDAL engine to stop, and exit the current form. Having described UI elements and action elements, "MoDAL Type" elements are now disclosed. As listed above, one type of MoDAL element is an integer having, for example, a syntax as follows: <INT>123</INT> to define the integer constant 123. Another MoDAL type element is the floating point decimal, defined as follows: <FLOAT>123.456</FLOAT> (which, in the example, defines the float constant 123.456). Still another MoDAL element is "character", which defines a letter, e.g., <CHAR>"A"</CHAR> defines the character constant "A". Furthermore, a string of characters can be defined using the syntax <STRING>"HELLO"</STRING>. In this example, the character string "HELLO" has been defined. Other elements can also be defined. For example, the element "ELEMENT" can be defined as follows: <ELEMENT name="element name" type="int".linevert split."float".linevert split."char".linevert split."string"></ELEMENT> In the preceding example, the "ELEMENT" syntax has been used to define a named element that can store the type of values defined in "type" entry. A value can be set using a "SET" action and retrieved with a "GET" action. Additional MoDAL grammar is set forth in the appendix at the end of the specification. Now referring to FIG. 4, a preferred architecture for use when the UIA 12 is embodied by an IBM Workpad.RTM. is shown. As shown, the source 40 of MoDAL applications (FIG. 2) can be established by an event loop 58 that is controlled by the operating system 60 of the UIA 12. The event loop 58 communicates events to the UIA engine 46, and more particularly to a UIA manager 62 and a UIA application processor 64. The UIA manager 62 manages the operation of a UIA communication manager 66, which communicates with the UIA application processor 64 to communicate data between the application processor 64 and either the TSpace proxy 26 (if the UIA 12 is connected to the network) or the local data cache 48 (when the UIA 12 is not connected to a network). Additionally, the UIA manager 62 controls the flow of data to the parser 42. As discussed above, the parser 42 transforms the above-disclosed MoDAL syntax to binary to extract GUI establishing instructions therefrom as part of the dynamic GUI establishment feature of the present invention. In response to the parsed GUI instructions of the MoDAL application received by the parser 42, the parser 42 accesses a library 68 of user interface classes. This library 68 contains the necessary GUI classes, i.e., definitions, of the MoDAL GUI elements that can be invoked by a MoDAL application. After retrieving the appropriate GUI classes from the library 68, the parser generates the application related data tables or streams 44 based on the specific GUI instructions contained in the particular MoDAL application being processed. More particularly, the parser 42 generates a list 70 of GUI resources (i.e., GUI elements that are to be used for the particular MoDAL application being processed). Each GUI resource in the list 70 is associated with a unique ResourceID, with the ResourceIDs being assigned in sequence starting from a numeric setpoint MoDALMANAGERTOP++1, for reasons to be shortly disclosed. Also, the parser 42 generates an elements list 72, which sets forth the various actions that have been associated with the GUI resources in the list 70 as defined in the MoDAL application. Each element node in the elements list 72 points to its parent and child nodes, its attributes, and its value. Each MoDAL element can be defined using the following syntax: <TAG attributes [more attributes]> <CHILDTAG attributes [more attributes]> </CHILDTAG> </TAG> As shown in FIG. 4, the UIA application processor 64 accesses the list 70 of GUI resources and elements list 72 during execution of the MoDAL application (i.e., during subsequent receipt of MoDAL application events for execution from the event loop 58) to dynamically present a GUI that can have been easily, quickly, and specifically tailored for the user of the UIA 12. The operation of the system architecture shown in FIG. 4 can be appreciated in reference to FIGS. 5 and 6. Commencing at block 74 in FIG. 5, the MoDAL manager 62 is started. Moving to block 78, a form is displayed to the user that lists the available MoDAL applications on TSpaces, or on the local data cache 48. At block 78, the event loop 58 (FIG. 4) is started, and then at block 80 the form listing the available MoDAL applications is loaded. From block 80, the process can move along two logical paths. Specifically, the process can move from block 80 to decision diamond 82, wherein it is determined whether the ResourceID of the current event in the event loop 58 is higher than a numeric setpoint referred to herein as "MoDALMANAGERTOP". No events, until they have been parsed by the parser 42 as more fully disclosed below, have a ResourceID greater than "MoDALMANAGERTOP". Accordingly, in the first iteration the test at decision diamond 82 is negative, and the process consequently moves to block 84 to continue the event loop 58 processing using the next event, sending the current event to the host operating system for processing. When, however, an event is found at decision diamond 84 to have a ResourceID greater than "MoDALMANAGERTOP", the logic moves to block 86 to pass the event to the UIA application processor 64 of the UIA engine 46 for execution of the event and/or display of the dynamically established GUI, as more fully set forth below in FIG. 6. Additionally, the logic can move from block 80 in FIG. 5 to block 88, wherein a user selection of a MoDAL application on the form of applications (presented at block 78) is received. Proceeding to block 90, the MoDAL application is sent by the manager 62 to the parser 42. The logic of the parser, at block 92, parses the application as described and, using the library 68 of UI classes (FIG. 4), generates the list 70 of GUI resources and elements list 72. From block 92, the logic moves to block 94, wherein the main form of the selected application is loaded by invoking the "FormGoTo" application programming interface (API) that has a ResourceID at least one greater than "MoDALMANAGERTOP". Proceeding to block 96, the main form is sent to the event loop 58, and the logic loops back to block 84 to continue processing as described. FIG. 6 shows the logic of the UIA application processor 64, once a MoDAL application has been processed by the parser 42. Commencing at block 98, the UIA application processor 64 receives an event from the event loop 58, the test at decision diamond 82 in FIG. 5 having been positive following the step at block 94 in FIG. 5. At block 100, using the ResourceID of the received event, the application processor 64 retrieves the event from the event list 72 (FIG. 4), if the event is present in the list 72. At block 102, it is verified that the event has indeed been found in the list 72, and if so, the event (associated actions, GUI presentations, etc.) is executed by the application processor 64. After executing the event at block 104, the application processor 64 returns a code to the event loop 58 at block 106, indicating that the event has been executed. Next, at decision diamond 108 it is determined whether the event was an application termination (i.e., an "appstop" event), and if it was, the logic moves to block 110 to load the MoDAL manager form (that lists the available MoDAL applications) and to set all ResourceIDs to less than the value of "MoDALMANAGERTOP". In contrast, if the event was not an application termination at decision diamond 108, the logic moves to block 112 to continue the event loop to continue executing the MoDAL application. Recall that at decision diamond 102 it is verified that the event has been found in the list 72. When an event is not found, the logic moves to block 114 to return a code to the event loop 58 indicating that event has not been handled by the application processor 64, and that the event consequently should be passed to the native (host) operating system for execution. The event loop is then continued at block 112. With the above architecture, logic, and MoDAL language description in mind, it can now be appreciated that the present invention generates UI components or elements, performs general computation, and interacts with both the local data cache 48 and TSpaces 28 such that real dynamic user interface rendering is undertaken and database and data caching functions are also undertaken. By "dynamic" user interface rendering is meant that the MoDAL language permits the user interface to be defined and modified on the fly both locally and remotely. Such adaptive user interfaces will be come more important as PDAs become more pervasive. In some cases, through simple learned behavior the UIA 12 can change the interface on the fly to better suit the user, and can also save the changed interface (and associative function) in the original application description, which can then be saved on a network server for permanent storage. Because the user interface can be generated on the fly, the interface can be composed in such a way that it is completely personalized to the end user based on a variety of parameters. The local database function advantageously gives all applications a uniform data representation, one that allows data to cross over from one application to the next. With this invention, the UIA 12 can be used as a universal remote control for any device, such as a television, and as a universal portal into any software program. Further, the UIA 12 can establish an adaptive interface infrastructure for special handicapped devices. Also, the UIA 12 can establish medical application interfaces for interacting with a complex database of information. FIG. 7 shows a preferred interface with TSpaces 28. First, the preferred TSpaces proxy 26 has the following structure: Buffer Length: Total length of the data being sent; Link ID: constant value used to identify the type of flow between the proxy 26 and UIA 12; TSSS TspaceSend( ) data sent from UIA 12 to the proxy 26; TSSR TspaceReceive( ) data sent from UIA 12 to the proxy 26; TSSQ TspaceQuery( ) data sent from UIA 12 to the proxy 26; TSRS TspaceSend( ) data sent from the proxy 26 to UIA 12; SRR TspaceReceive( ) data sent from the proxy 26 to UIA 12; and TSRQ TspaceQuery( ) data sent from the proxy 26 to UIA 12. The proxy 26 includes a data buffer that contains an array of fields up to the total length of the buffer, with each field having the following structure: Field Length: length of the field, including length, type and value; Type: type of value stored in the field; and Value: value stored in the field. This part of a field does not exist in the case wherein a TspaceQuery( ) is sending only a data type with no specific value. With above preferred proxy 26 in mind, FIG. 7 shows that the UIA 12 communicates with the proxy 26 as described previously, with the proxy 26 in turn communicating with TSpaces 28. A MoDAL application can be used to send tuples to TSpaces 28, with the tuples having a defined tuple structure. An interface application (registered at the Tspaces server) will be listening, expecting to receive these specific tuples. The listening application will attempt to identify the received Tuples as data intended to be sent to a Lotus.RTM. Notes.RTM. database 112 (or as a query request for Lotus Notes). The predefined tuple structure makes it easy for the MoDAL programmer to specify the tuple as an instruction or data that the interface will receive and will perform some action to obtain to send/update data from the database 112, while passing a minimum number of Notes parameters. A listener waits for information to be written to a TupleSpace (TransTupleSpace). An API call to, e.g., the database 112 will depend on the request (key). The return code that is returned from Notes is handled by a return code class 113, which places this return code on the TransTupleSpace (key=TTSreturn). The main Java-language module of a translistener class 114 registers a callback class 115 with the TSpaces 28 server. When a certain tuple is written to the TransTupleSpace, the translistener call back class 115 is called with the tuple information. This information is routed by calling a notes thread class 116. This class 116 should process the information or call another class to do so. ##SPC1## ##SPC2## ##SPC3## ##SPC4## ##SPC5## ##SPC6## ##SPC7## ##SPC8## ##SPC9## While the particular UNIVERSAL INFORMATION APPLIANCE as herein shown and described in detail is fully capable of attaining the above-described objects of the invention, it is to be understood that it is the presently preferred embodiment of the present invention and is thus representative of the subject matter which is broadly contemplated by the present invention, that the scope of the present invention fully encompasses other embodiments which may become obvious to those skilled in the art, and that the scope of the present invention is accordingly to be limited by nothing other than the appended claims.
|
Same subclass Same class Consider this |
||||||||||