Skip Ribbon Commands
Skip to main content

Quick Launch

9/6/2012 9:00 PM
Random Note
Basic functions:
-wiring together 2 terminals (creation of terminals handled by module creation)
-sending data from one terminal to another
-disconnecting terminals

-wire a local and network terminal
-wire a local terminal to a network after user on other side of network has disconnected due to user crash (i.e computer crashed)
-wire network terminal to local after network crashed (wireless goes down)

sending data:
-sending data across after 1 user crashed (i.e comp crash)
-sending data across after network crashed (wireless goes down)

disconnecting terminals:
-disconnect network and local terminals after 1 user crashed
-disconnect network and local terminals after network crashed

Remote Modules
NC= Network crash
UC = user crash

-trying to use a remote module after UC/NC
-trying to add a remote module to a composite module after UC/NC
-trying to create a new instance of a composite module which contains a remote module after the host of the remote module has DCed (also for UC/DC)
9/7/2012 7:50 PM
8/29/2012 3:00 PM
Outside Class Meeting

​Basic Functionality of Modules:


- how modules are created

- how modules do computation

- how to create composite modules

Module Implementation Details


- one output vs multiple output

- need to have composite pattern

- decided on multiple output possible

- observable pattern

- when add new module, pull result from previous module

-> new module listener to input modules

composite modules

- connect smaller modules into inputs and outputs on the side of the screen

Remote modules:

- modules can do whatever the f*** they want

- strategy pattern & get rid of module shell

8/29/2012 2:13 PM
8/26/2012 12:00 PM
Outside Class Meeting

Attendance: Kevin, Frank, Adrien

  • Going over the spec
    • Generalization of Module
      • Any number of inputs, any number of outputs
      • Composite design pattern for Modules
      • We should propose specific OO design for these
        • Adrien and Frank will each draft a proposal to present to team on Monday
    • Networking
      • Computation for each module should happen on the computer that’s hosting it
      • What happens if a client loses connection? His modules should disappear from everybody else’s palettes.
    • Push/Pull
      • Adrien proposes using Event model (Observer/Observable) to handle flow of data through a circuit. It effectively ends up being a push pattern, but by using the event pattern we modularize the modules a bit more cleanly.
  • How do remote modules work?
    • When I put a remote module on my circuit board, is the module instance that backs that ui element created on the hosting machine? It must.
    • It would be nice to have a remote module stub that looks exactly like a normal module, but makes the RMI calls to the host machine. Basically make the network as transparent as possible.
  • Talking about the Event pattern. And how does that work across the network?
    • When we attach a module to another module, we need to:
      • Get the value at the output of the upstream module
      • Subscribe to events from the output of the upstream module
    • Input Terminal is listening to the Output Terminal, or is it listening to the Module itself?
      • Depends on whether we allow multiple outputs on a module. To be decided Monday after the 2 proposed designs.
  • We should have our own TFS branch.
    • Frank will manage our team’s TFS.
    • Our team’s TFS system will be set up by end of class Monday.
  • Action Items
    • Kevin will meet with other sub teams to discuss progress and API decisions.
    • Frank and Adrien will draft proposals for Module design (1 ouput vs. multiple output)
    • Kevin will look more into Computation Manager
    • Frank will set up our TFS by class Monday

8/26/2012 1:44 PM
8/24/2012 4:00 PM
Random Note

​Add notes about your thoughts on the Modules Code

8/24/2012 3:44 PM