Carrie's Meeting Notes
Attendees: Carrie, Archie, Kevin, Damien, Apoorv, Randy
8/27/2012 7:00 p.m.
Connect Modules * - should be connecting inputs/outputs
Save Module - create composite module, save to palettte
Q: Where are the number of input/outputs stored?
A: In the Pallette.
Note: Check needs to be done before we connect the modules, make sure all inputs/outputs connected & no hanging terminals.
Event Observer: 'Shell' on input terminal. Notices when changed.
Network communications, currently pretty complication
Pull goes to remote stub of module, which creates a unique ComputationInstance which communicates with the ComputationManager which then requests a value from the other computer, which eventually sends a response.
Need Network services, but not sure which yet, until we decide on a design to improve the above previous strategy from F11.
Biggest Issue: GUI code keeping track of who it's connected it.
GUI shouldn't need to know who it's connected to, Network should track who's connect to who and provide that info to the GUI when needed (i.e. just connected, disconnected, etc.). GUI should just say that the local machine is disconnecting, and the Network sends that message to everyone.
So, Network API needs: 1) An I-am-disconnecting method
2) An I-want-to-disconnect-from-peer(PeerID) method
Next Issue: When connecting to an individual, connector gets both palettes, and host sometimes does not get new palette (Randy cited instance when both received palette).
Cross Issue: Decided on not having a Framework when discussing whoshould keep the list of modules.
Current issue with old project, when you hook up a remote module, the result isn't stored correctly into your dictionary, so a 'key not found' error occurs.
Question: In OwlVIEWData\Palette, what does makeSafe/makeDangerousdo?
Answer: Networking needs to look more into that.
Question: Where do we store the list of modules I need
Anwer: In the network because they're already keeping track of who's connected to who, and an app's modules run hand-in-hand with that.
Networking needs converse for all it's services. Example: You wantbthem to compute something, they need somewhere to store the result.
Start off with the one controller idea, we can add a Model controller later easier than we can go from two to one.
Question: Who does this controller allow to talk to each other?
Conclusion: Module on local machine should keep track of state, remote module only required for actual computation. Module is the product of the factory method, while the palette window holds a sort of 'meta data' about the available module.
So, controller only creates the adapters between the Modules/Network/GUI, does not actually create an object or adapter.
When moving outside your sandbox, just add a method to the interfac documenting what you need it to do (inputs, outputs, who it's talking to, etc.). And we can contact the correct team with your outward-facing interface.
Get in contact with team => up to date on meeting decisions, design of your team, etc.
Provide an interface with what you NEED of other services. With documentation!!
Provide a document about what methods/information of what you provide. With documentation!
Reminder: Start making a report of what your teams are choosing vs. last year on an outline/rough draft (due Wed in class!) so that we can eventually use it on our final report.