!! Notes for BRIDGE Architecture overview
_
Intro:
- Brief high-level technology overview is available on the NAVCIITI project site: */projects/navciiti/Technology*
- Parts:
-- CORK provides object replication services
-- Components that provide UIs for manipulating CORK
-- BRIDGE provides ways of organizing CORK objects and finding UIs for them
-- Environment implementations use bridge

! CORK
- Tutorial is on the java web page (*http://java.cs.vt.edu/*) under the "Tutorials" link
- General architectural overview:
<CENTER>
\/projects/navciiti/client-server-layers.jpg\
</CENTER>
- Generality and efficiency comes from the way we detect and propagate modifications, the "Object Replication Services" layer in the diagram above:
<CENTER>
\/projects/navciiti/map-sessions.jpg\
</CENTER>
- Note that the CORK server inherently has <B>no</B> knowledge of application semantics.
- CORK Elements:
-- <CODE>ObjectID</CODE> are opaque "pointers" that uniquely and persistantly identify replicated objects. ObjectID are the standard way to retrieve a replicated object from the server.
-- Listeners are attached to replicated objects to detect local changes. These are generally the same kind of listeners needs for UI changes in MVC-ish systems.
-- <CODE>Change</CODE> objects are generated by listener objects and broadcast to the server, where the master replica is updated. Each <CODE>Change</CODE> is then sent to any other active client.
-- A <CODE>Permissions</CODE> object is registered with each replicated object in the server, and has the ability to veto any request to retrieve or modify an object, based on any criteria it wants (user name, <CODE>Change</CODE> characteristics, user host, time of day, etc...).

! Component user interfaces
- Each type of replicated object usually has one or more Java interface and/or web interface for presenting and/or editing objects of the given type.
- The LiNC notebook, MOOsburg, and collab presentation tool efforts all represented attempts to build environments that provided access to sets of UIs for sets of replicated objects.
- BRIDGE represents "lessons learned" from these attempts

! BRIDGE
- Requirements and corresponding interfaces:
-- Object meta-data
--- Aside from the ObjectID, user interfaces need to know things about an object that are best kept separate from the object itself.
--- Standard meta-data includes object name and last modification time/user. Other meta-data will likely be specific to specific environments or services.  
--- <B><CODE>EmbeddedObjectDescriptor</CODE></B> specifies an interface that these meta-data objects should conform to.
-- Object grouping and structure
--- Objects are logically grouped into sets, and sets can be organized into hierarchies. (Other organizations possible, too.)
--- Sets may be topical/manually created (like directories in a file system) or derived based on object characteristics. With good abstractions, the same UI elements should be able to work on either kind of set.
--- The <B><CODE>EmbeddedObjectSet</CODE></B> interface specifies methods that a container for a set of objects should implement.
--- <B><CODE>EmbeddedObjectPath</CODE></B> implements a record for a "path" through a hierarchy of <CODE>EmbeddedObjectSet</CODE>s, terminating at an <CODE>EmbeddedObjectDescriptor</CODE>.
--- We've re-invented the hierarchical file system! Other organizations are certainly possible, but hierarchical structure is "comfortable", maps nicely to URLs, and other data organizations can be created in parallel.
-- Interactive interfaces
--- For each kind of replicated object there may be one or more Java (Swing/AWT) components that support presentation or interaction.
--- In practice, these components have a life cycle similar to that of applets: construction, initialization, notification when the object has actually been loaded, activation (when shown), and deactivation (when hidden).
--- The <B><CODE>ComponentView</CODE></B> interface provides an abstraction for these UI elements that support the component life cycle. A default implementation of this interface exists that provides some concrete funcationality.
--- The <B><CODE>ComponentViewSource</CODE></B> interface defines how a registry for mapping CORK ObjectIDs to <CODE>ComponentView</CODE> instances should behave. The default implementation simply implements a static object-class to ComponentView-class mapping, though more interesting behaviors could be implemented.
-- Web interfaces
--- Standard tools like servlets and jsp provide a way to generate data for delivery via HTTP
--- For a given object, however, we need:
---# To determine in what MIME-types can it be rendered
---# To know what servlet should be used to render it "by itself"
---# To have a way to write "inlined" content of a supported MIME-type to a stream, without http headers or other object-specific presentation data that would normally be present when rendered by a servlet
--- The <B><CODE>WebView</CODE></B> interface provides an abstraction for objects that handle these tasks for a given kind of replicated object
--- The <B><CODE>WebViewSource</CODE></B> interface defines how a registry for mapping CORK ObjectIDs to <CODE>WebView</CODE> instances should behave.
- Once there are standard ways of locating objects, retrieving them, and generating web or java UIs for them, we can build lots of generic services:
-- UI Components for:
--- Displaying a ComponentView for a single object, with standard progress bars and other feedback (<CODE>ComponentViewPanel</CODE>)
--- Displaying a menu bar for a single object (<CODE>ComponentViewMenuBar</CODE>)
--- Displaying and modifying permissions on an object (<CODE>PermissionsLabel</CODE> and <CODE>PermissionsPanel</CODE>)
--- Presenting draggable/droppable lists and trees of objects
--- Displaying sets of components in list, tabbed, or layered views
-- Standard mechanism for tracking who is accessing which objects
-- Standard <CODE>DispatchServlet</CODE> for turning a URL into an <CODE>EmbeddedObjectPath</CODE>, which can then be used to look up a replicated object, find a <CODE>WebView</CODE> for it, and send the data back over an HTTP connection.
-- Updating modification info and creating versions
-- Search index maintenance

- Extremely minimal tutorial on *http://java.cs.vt.edu/* describes how to start a bridge client and server.