Jarl wrote: > OK, here comes MY partial view on vsh. Jean & Brad & Jeff: please fix and > expand > this! I took a stab at my two assigned parts. Comments are very welcome :-) Interface <-> DL: The user interface communicates with the functional parts of vsh through a streaming XML dialog with the definition layer. This dialog occurs in the form of a request and response interchange between the user interface and the definition layer through a local socket. For instance, to request the addition of a processor node (program) to the workspace, the user interface would send the following XML request to the definition layer: <ui> <add> <workspace id = 'workspace1/workspace2'/> <node type = 'processor'> </add> </ui> The definition layer would then process this message, perform the requested operation, and if the operation was successful, return information to the user interface in the response: <dl> <success> <node id = 'newly assigned node id' num_inputs = 'number of initial inputs' num_outputs = 'number of initial outputs' ui_name = 'name of the UI type' /> </success> </dl> or return an error message if there were problems. The design of this interface to definition layer communication allows multiple user interfaces to be created on the same definition and processing layer internals. In addition, these user interfaces can be created in any programming language supporting XML manipulation tools and sockets. DL internal: Thw definition layer provides the glue which connects the user interfaces with the processing internals of vsh. It is responsible for a number of functions: 1. Maintaining communication with multiple user interfaces through a streaming XML dialog communication protocol. 2. Storing of work-flow diagrams from the user interfaces in an XML format. This XML models the nodes present in the user interface and the connections/interrelationships between them. 3. Maintaining a permanent storage location for specially designed nodes that represent specific programs and libraries. The information for these nodes will be stored as XML and be available directly available to the user interface through the streaming XML dialog. 4. Communication with the processing portion of the program be implementing a CORBA client to a server in the brokering layer. This communication allows work flow diagrams to be passed to the processing layers for implementation, and allows a process to be queried while running. 5. Communication with remote vsh programs as both a client and a server using corba (through an idl that still has to be defined). This allows a specific implementation of vsh to serve out a specialized node or set of nodes to be utilized by other vsh implementations at remote locations. The processing layer will handle the specifics of this communication, but the middle will define a protocol to authenticate remote vsh implementations and provide access only to available nodes. The definition layer is implemented in the python programming language and relies on freely available XML and DOM libraries. CORBA communication will occur using the Fnorb ORB implementation, but will eventually move to ORBit (using ORBit-python) as work on python bindings for ORBit continues.