Personal tools
  • We're Hiring!

You are here: Home Community Minutes Meetings Baltimore 2003 Meeting

Baltimore 2003 Meeting

Notes on Savings Settings for OME User Clients

19 November 2003

Some notes on data types that will be needed to store settings for
user client software in the OME database.

These note are in English - appropriate translation to XML will be
needed once the details are nailed down.

Assume that we have a universe of user clients. The OME database has a
table with an ID number, a name, and a description for each of the

Application Settings

Each application would have a set of semantic types which would be
defined to store any settings that applied across the entire
application. These semantic types would have elements of the form
(<application id, user id, timestamp >) where remaining fields specified
the state of each type of setting. For any <application id, user id>
pair, the most recent entry should be considered current, with others
being historical.

Application Windows

Each client will have somewhere between 1 and n top-level operating
system windows. Each one of those windows will have an ID
number. These window IDs will be used to indicate the type of a
window. They need not be unique _across_ applications but they must be
unique _within_ an application.

For example, if the OME Chain builder is application #3, and chain
windows within this application are window #1, windows of type
<3,1> (<application id, window type>) are chain windows within the
chain builder. Windows of type <4,1> perform some different function
in application #4.

This may seem undesirable, as it creates the situation where both the
application ID and the window ID are needed as a primary key to
identify an instance of a window. However, it has the advantage of
not requiring that the database have any information about the
functioning of individual clients. Alterantive schemes - such as
issuing a unique identifier for each <application id, window type>
pair - might require more complex interactions between the clients
and the database.

Mapping from window types to window instances is accomplished by a
table that contains rows of <application id, window type,
user id,window_ id,timestamp> tuples. The window_id field _is_
unique across all applications, so it can be used to unambiguously
identify a window and -via this table - the application context in
which it exists.

The user id obviously indicates the user responsible for creation
of the specified state. For any given <application, window_type>
combination, the most recent setting should be used, with other
entries considered as historical.

the position of a window is given by a client_window_position table,
which contains tuples of the form <window_id,x,y,width,height>, where
x,y, width, and height are integer values with the obvious semantics.

Window Specific Settings

Like application-wide settings, the contents of various windows would
be stored in application-dependendent semantic types. In addition,
window-specific settings would be keyed off of window_id.

For example, a window that contained a slider used to specify a value
parameter such that min <= value <=max might have a semantic type
with the following elements: <window_id, control_id,min,max,value>
(all of which are ints).

Alternatively, the chain builder application may have a chain canvas
that contains several modules and links. The modules might be
represented by <window_id,module_id,module_instance_id,x,y>, where x
and y are the coordinates of the module in the chain. The
module_instance_id is a unique value that can be used to distinguish
between multiple instances of a module in one chain. Each link will
be defined in two parts.

First a tuple that defines the link and its endpoints:
<window_id,link_id,start_module_instance,end_module_instance>. Link_ids
are unique within applications, but not across
applications. Start_module_instance and end_module_instance correspond
to module_instance_id values as described above.

The second component of the link is a list of x,y positions that
define the trajectory of the link on the screen. These positions are
all relative to the containing window. There will be one tuple for
each point in a link, with the contents <window_id,link_id,link_position,x,y>,
where link_position ranges from 0 (the start of the link) to n-1 (if
n is the number of points in the link).

Additional types for application-specific settings will be defined as

Images from meeting

Document Actions